On Fri, Jun 05, 2026 at 12:23:48 +0200, Radoslaw Smigielski via Devel wrote:
On Mon, 1 Jun 2026 at 14:32, Peter Krempa <pkrempa@redhat.com> wrote:
On Fri, May 29, 2026 at 16:46:58 +0200, Radoslaw Smigielski wrote:
[...]
Another issue is that if you'll have:
<filesystem type='file' accessmode='passthrough'> <driver type='loop' format='raw'/> <source
file='/root/someveeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeerylongpath/a.raw'/>
<target dir='/'/> </filesystem> <filesystem type='file' accessmode='passthrough'> <driver type='loop' format='raw'/> <source
<target dir='/'/> </filesystem>
They'll be truncated to the same string.
So I tried to follow the same logic like losetup from util-linux uses to handle long paths: - takes the first 63 bytes of the absolute path - no intelligent path shortening (like keeping the filename and truncating middle) - adds an asterisk at position 62 to indicate the name was truncated
lo->lo_file_name[LO_NAME_SIZE - 2] = '*'; // Position 62 gets '*' lo->lo_file_name[LO_NAME_SIZE - 1] = '\0'; // Position 63 is null terminator
Above indeed can result in non-unique or unhelpful loop device names in
file='/root/someveeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeerylongpath/b.raw'/> the
kernel's loop_info64 structure.
So ... the most important question is how the value is used (which I don't remember any more).
If it's visible or used from withint the LXC instance, then we must not change it. The users are out of luck unfortunately.
If it's just informative and we can change it (and based on the fact that it's being truncated so it doesn't reflect anything real) we could also replace it by a controlled string which is unable to exceed 63 chars without truncation.
It could be something like:
'libvirt-$UUID-$DEVALIAS'
Question if we should mimic the same logic or imlement someting smarter.
It really depends on what the semantics are; see above. If it can be changed though I'd go for something more stable for the future.
Addint "*" before '\0' to indicate truncation would make it compatibile with losetup behavior.
I'm not sure if that's too valuable of a behaviour. It prevents you from identifying the resource. Having an indentifier allowing you to look up the path would make more sense.
...
Well, now you see why this issue lingered so long. There are plenty corner cases that need to be checked and behaviour analyzed :)
So one more attempt ;) This time no patch but some short analysis and summary.
There seems to be only one command which shows or use lo_file_name: losetup -l -O +REF All other commands or files in /proc or /dev do not contain lo_file_name.
Example of the losetup command output goes like below, where last REF column is a value of lo_file_name:
[root@rvm10 radek]# losetup -l -O +REF NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC REF /dev/loop1 0 0 1 0 /root/someveeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeerylongpath/a.raw 0 512 /root/someveeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee* /dev/loop0 0 0 1 0 /root/disk2.raw 0 512 /root/disk2.raw
But important point here is that the lo_file_name/REF is being truncated above by losetup/kernel.
Okay, so it really seems to be just an identifier rather than the path itself.
If it's visible or used from withint the LXC instance, then we must not change it. The users are out of luck unfortunately.
lo_file_name is not visible or meaningfully accessible from within the LXC container. In LXC container:
1. From /proc inside container:
- /proc/partitions - Shows only device names like loop0, NOT the backing file path
- /proc/mounts - Shows the mount point and device (/dev/loop0), NOT lo_file_name 2. From /sys inside container: - /sys/block/loopN/loop/backing_file - Shows the real path from the kernel's open file descriptor, NOT from lo_file_name - There is NO /sys/block/loopN/loop/ref or similar file that exposes lo_file_name 3. losetup inside the LXC domain (container) does not show values in REF column:
sh-5.3# losetup -l -O +REF NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC REF /dev/loop1 (lost) 0 0 1 0 /root/someveeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeerylongpath/a.raw 0 512 /dev/loop0 (lost) 0 0 1 0 /root/disk2.raw 0 512
So making the long story short: - Linux kernel does NOT use lo_file_name to open or read the file. I/O goes through the fd passed to LOOP_SET_FD. - There is no code path where the kernel opens, resolves, or reads the backing file using lo_file_name. - LXC never reads or acts on lo_file_name. It is written once and left for the kernel and external tools. - The kernel's memcpy(lo->lo_file_name, info->lo_file_name, LO_NAME_SIZE) just stores it for LOOP_GET_STATUS64 queries - it's not used for I/O.
It could be something like:
'libvirt-$UUID-$DEVALIAS'
Perer, just to make sure I fully understood. What would be $DEVALIAS ? loop device name ? last 19 characters of the file path?
It's the alias of the device. Libvirt normally auto-allocates them at startup: <filesystem type='mount' accessmode='passthrough'> <driver type='virtiofs'/> <binary path='/usr/libexec/virtiofsd'/> <source dir='/tmp'/> <target dir='/'/> <readonly/> <alias name='fs0'/> ^^^^^ <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </filesystem> it's stored in 'fs->info.alias'. Now as you see the alias is normally short but users can pass their own ...
DEVALIAS would need to fit into 19 characters. 64 - len('\0') - len('libvirt-$UUID') = 19 chars
... so this would effectively limit them to 19 characters. I guess that's an okay limitation because normally users don't set those. We should fail though if the user picks some massive string because we'd run into the same problem.
But I agree that this format of the name 'libvirt-$UUID-$DEVALIAS' would be easier for debugging and troubleshooting potential problems. We could fit into 63 characters. And finally it would be unique and deterministic.
Because all above, it's much better approach than what I implemented with truncating and '*'.
---------------------- < Tℏanks | Radek >