non-unique device-inode when snapshots are mounted

[madroach]

I stumbled on this error when restoring an accidentally overwritten file from a recent snapshot:

% mount |grep /dev/nvme0n1p5
/dev/nvme0n1p5 on /home type nilfs2 (rw,noatime,nodiratime,discard)
/dev/nvme0n1p5 on /mnt type nilfs2 (ro,relatime,cp=38290,discard)
% ll /mnt/madroach/Verwaltung/Zeugnisse/Approbation.pdf /home/madroach/Verwaltung/Zeugnisse/Approbation.pdf 
-rw-r--r-- 1 madroach users 1,1M 25. Sep 14:42 /home/madroach/Verwaltung/Zeugnisse/Approbation.pdf
-rw-r--r-- 1 madroach users 253K 28. Nov 2014  /mnt/madroach/Verwaltung/Zeugnisse/Approbation.pdf
% cp /mnt/madroach/Verwaltung/Zeugnisse/Approbation.pdf /home/madroach/Verwaltung/Zeugnisse/Approbation.pdf  
cp: '/mnt/madroach/Verwaltung/Zeugnisse/Approbation.pdf' and '/home/madroach/Verwaltung/Zeugnisse/Approbation.pdf' are the same file
% cp -f /mnt/madroach/Verwaltung/Zeugnisse/Approbation.pdf /home/madroach/Verwaltung/Zeugnisse/Approbation.pdf 
cp: '/mnt/madroach/Verwaltung/Zeugnisse/Approbation.pdf' and '/home/madroach/Verwaltung/Zeugnisse/Approbation.pdf' are the same file

This is because cp checks file sameness by comparing st_dev and st_ino. Of course this is easy to work around by doing first a copy with temporary name, then mv.

Im not sure what the semantics of st_devandst_inoare supposed to be when different versions of the same filesystem on the same device are mounted. I don't thinkcpis to blame. Expecting files with identicalst_devandst_inoto be identical is a sane assumption. nilfs2 also does nothing unexpected. To me it seems the underlying problem is the assumption that a single partition (identified byst_dev`) can only over house a single filesystem. Nobody thought about multiple versions of a filesystem.

At fist look disambiguating by changing st_dev on snapshot mounts would be most straightforward, but this would lie about the device on which files are actually stored.

Disambiguating by tweaking the inode numbers on the other hand could be straightforward. Since nilfs2 uses 64bit inodes it could reserve some bits in the inode numbers to use for disambiguation.

[konis]

Thank you for filing this issue and your detailed description. It's true that this problem exists.

Possible solutions include:

• Changing the inode number to deceive users when mounting a previous checkpoint, as you pointed out (A)
• Changing the device number, as you also pointed out (B) or
• Changing the inode number when the file version changes, as some versioning and copy-on-write filesystems do. (C)

There are other approaches, such as providing alternative tools or providing modifications to the tools, but we'll leave those out of the discussion here.

Each approach has its pros and cons.

(A) is compatible with the current NILFS2 implementation, but applications that store inode numbers as 32-bit integers may experience overflows or inconsistencies, so care must be taken when designing the inode number bit field.

(B) seems natural in terms of compatibility with the VFS layer, but as you pointed out, it makes it unclear which device the file resides on. Assigning different device numbers to the same device may violate some of the assumptions of other functions, such as udev and mount monitoring tools, and cause them to break.

(C) is highly consistent with other snapshot-compatible file systems and UNIX-like systems, but it requires fundamental overhauls and is a difficult approach for NILFS2. Care must also be taken to prevent hard links from breaking.

In any case, this is not a matter of bug fixes, but rather an issue that requires fundamental consideration and feature enhancements.