Hi, Andreas B. Mundt wrote: > looking at the inode numbers of the loop > mounted live images shows that files with identical names share the > same number. > [...] > https://lwn.net/Articles/895444/
I cannot match this article with the peculiarities of mounted ISO 9660 in Linux. It seems to be about multiple snapshots inside a filesystem. There is no such thing in ISO 9660 except possibly the alternative directory tree of Joliet. But Linux only mounts either ISO 9660 (+ Rock Ridge) or Joliet, not both. Linux computes the inode numbers in mounted ISO 9660 filesystems from the byte address of the directory record which describes the file. https://github.com/torvalds/linux/blob/master/fs/isofs/isofs.h line 143 ff. Since the minimum record size is 34, the number can be divided by 32, i.e. bit shifted by 5, without losing uniqueness. > 6218 filesystem.squashfs $ expr 6218 '*' 32 198976 $ dd if=debian-live-12.0.0-amd64-standard.iso bs=1 skip=198976 count=64 | od -c shows 0000000 t e m . p a c k a g e s 214 \0 357 335 0000020 \0 \0 \0 \0 335 357 \0 020 262 B B 262 020 \0 { 006 0000040 \n \b 3 021 \0 \0 \0 \0 001 \0 \0 001 025 F I L 0000060 E S Y S T E M . S Q U A S H F S (The directory record begins by "214". 34 bytes further begins the dull ISO 9660 filename. We also see the end part of the previous file's Rock Ridge name.) So identical inode numbers in different ISOs indicate nearly identical directory content at least at the beginning of the directory trees. If NFS has problems to keep them apart, then either it drops the dev_t numbers of the inodes or the host system is broken by not giving different dev_t numbers to different loop-mounted ISO 9660 systems. Maybe this article gives hints about what is happening: https://utcc.utoronto.ca/~cks/space/blog/unix/NFSMultiFSFault Have a nice day :) Thomas
