On Mon, 1 Jun 2026 at 14:32, Peter Krempa <[email protected]> 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
> >
> file='/root/someveeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeerylongpath/b.raw'/>
> > > <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
> 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.
> 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?
DEVALIAS would need to fit into 19 characters.
64 - len('\0') - len('libvirt-$UUID') = 19 chars
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 >
