an irritating problem and possible source of quiet data loss

[dexen deVries <dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Hi,

theres' that irritating problem that two files on the same device and with same 
pathname -- but different content -- can have same inode number on NILFS2. It 
really can screw automated and manual backup/restore. Best of all, it seems to 
be against POSIX. Actually, two `versions' of the same file.

Today I wanted to revert a config file to certain older version:

(/dev/sda3 is the current root filesystem)

# chcp ss /dev/sda3 7591068
# mount /dev/sda3 /mnt/x -o ro,cp=7591068
# diff -burN /etc/adjtime  /mnt/x/etc/adjtime | diffstat
 adjtime |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

so far so good. However!

# cp etc/adjtime /etc
cp: `etc/adjtime' and `/etc/adjtime' are the same file

and it did /not/ copy the original version over the new file.


The thing is, till recently the `diff' would also (errorously!) not report 
difference between those two files, because it relied on comparing device and 
inode numbers. If those matched, the files must be the same file. Just like 
pointer equality in C programming language: if two objects are located at the 
same address (pointer equality), they are the same object.

MVFS (a ClearCase thingie) and NILFS2 break that; diff now contains special 
workaround because of MVFS. But some other utilities do not.

From diff's sources:
> POSIX says that two files are identical if st_ino and st_dev are
> the same, but many file systems incorrectly assign the same (device,
> inode) pair to two distinct files, including:
> 
> ((short list: Linux NFS, Network Appliance NFS, MVFS)) 

Please consider fixing that: either report different inode numbers on mounted 
snapshots, or use different device numbers for mounted snapshots. The later 
could make more sense -- a snapshot of filesystem is a much different entity 
than the current state -- and also could be way easier to implement in kernel 
without changing filesystem format.

Before any fix is ready, a manual workaround is possible, by using loop device:

coil!root!/mnt # losetup -f -v /dev/sda3
Loop device is /dev/loop0
coil!root!/mnt # mount /dev/loop0 /mnt/x -o cp=7591068,ro
(now /dev/loop0 mounted at /mnt/x has different device ID than the root 
filesystem at /dev/sda3)
coil!root!~ # cp /mnt/x/etc/adjtime /etc/adjtime 

(worked!)


Regards,
-- 
dexen deVries

[[[↓][→]]]

For example, if the first thing in the file is:
   <?kzy irefvba="1.0" rapbqvat="ebg13"?>
an XML parser will recognize that the document is stored in the traditional 
ROT13 encoding.

(( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt ))
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html