Skip to contentSkip to conversation

an irritating problem and possible source of quiet data loss

DISCUSSION dexen deVries 2 participants 3 messages Aug 17, 2011 – Aug 23, 2011 1 message not in the archive NILFS2 filesystem

lore
Share & tools
lore

dexen deVries

author
#0 lore raw

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:

Quoted 5 lines

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,

Signature · 14 lines
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 201108171207.22032.dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

author
#2 lore raw
Quoted 7 lines · On Wednesday 17 of August 2011 14:07:21 i wrote:

(...)
so far so good. However!

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

(...)

a small clarification: at this moment, i was in /mnt/x/, so the source file to be copied was actually /mnt/x/etc/adjtime -- the older version i wanted to restore.

Signature · 14 lines
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#3 lore raw
In reply to a message not in the archive
Quoted 26 lines · dexen deVries

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.

Quoted 6 lines

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.

Yes, this is a known and essential problem of the snapshot mounts in nilfs.

Quoted 8 lines

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:

Quoted 4 lines

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:

Quoted 7 lines
Quoted 1 line

((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.

Some filesystem uses anonymous block device to avoid this issue, but the number of anonymous devices is limited to 127 per system.

We often make concurrent snapshot mounts whose total number is larger than this. A compromise for this issue is adding mount option which switches reusing the original block ID or assigning a new block ID for snapshot mounts.

-- I don't know if we can actually do this, but I agree that it is a problem to be handled in some way.

Quoted 10 lines

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!)

Thanks for reporting the workaround.

Regards,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html