On Wed, Aug 16, 2023 at 05:25:26PM +1000, Craig Small wrote: >> $ stat -L /usr/lib/x86_64-linux-gnu/libc.so.6 >> >> File: /usr/lib/x86_64-linux-gnu/libc.so.6 >> Size: 1922136 Blocks: 3760 IO Block: 4096 regular file >> Device: 0,27 Inode: 1834061 Links: 1 >> > [...] > >> $ grep -F libc.so /proc/$$/maps >> 7f6c81da2000-7f6c81dc8000 r--p 00000000 00:19 1834061 >> /usr/lib/x86_64-linux-gnu/libc.so.6 >> >> It looks like there is a disagreement about which device the file's on: >> 0,27 vs. 00:19 (i.e., 0,25).
> So, why is the device id different? It might be something odd with that > filesystem, but it could be mount namespaces. > Do you know if you have those? / is btrfs with just the single subvolume (to my knowledge), set up by the Debian installer. # btrfs subvolume list -a -t / ID gen top level path -- --- --------- ---- 256 42766 5 <FS_TREE>/@rootfs > What does > grep -e ' 0:2[57] ' /proc/self/mountinfo > show? 29 1 0:25 /@rootfs / rw,relatime shared:1 - btrfs /dev/sda3 rw,compress=zstd:1,ssd,space_cache=v2,subvolid=256,subvol=/@rootfs It looks like interpreting the device number may be a problem with btrfs: https://lwn.net/Articles/866582/ "... the filesystem allocates a separate device number (the usual major/minor pair) for each subvolume; that number can be seen with a system call like stat(). [... Those] numbers do not show up in files like /proc/self/mountinfo, leading to inconsistent views of how the filesystem is put together." > You could also try > sudo nsenter -a -t <pid of process> fuser > /usr/lib/x86_64-linux-gnu/libc.so.6 This doesn't seem to produce any output.
