Re: mounting live ISO images, inodes and NFS

["Thomas Schmitt" <scdbackup@gmx.net>]

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