Need ideas on how to solve an st_ino/st_dev test issue for HAMMER.

Matthew Dillon dillon at apollo.backplane.com
Sun Mar 30 15:11:03 PDT 2008


    Here's the problem, given historical access softlinks as shown below:

test30# ls -lda cra*
drwxr-xr-x  1 root  wheel  Mar 29 13:04 crater
lrwxr-xr-x  1 root  wheel  Mar 29 18:57 crater.20080329 -> crater@@0x47eef383
lrwxr-xr-x  1 root  wheel  Mar 30 01:24 crater.20080330 -> crater@@0x47ef4e29
-rw-r--r--  2 root  wheel  Mar 30 01:24 crater.log

    The problem is that if I do this:

    diff -r crater.20080329/var/log crater.20080330/var/log

    Diff just returns without actually diffing anything.  The reason is
    because diff checks st_ino and st_dev and believes the directories/files
    to be identical because they match.

    I considered munging the inode number for historical accesses, but
    that would seriously break NFS exports which try to access historical
    files and directories.  Right now NFS *is* able to distinguish between
    the two because NFS handles are 128-bit-wide entities, so I can encode
    the as-of transaction id as part of the filehandle.  But userland
    programs only have access to a 64-bit-wide inode so userland still
    believes the files to be identical.

    st_dev is only 32 bits, carefully munging it is an option if we
    could figure out a way to do it, but I'd rather not.

    I am considering using st_gen but then we'd have to patch third
    party software to test st_gen along with everything else.  This may
    be the only workable solution, though, and only a few programs would
    need to be patched.  st_gen is only 32 bits but it would solve the
    problem as we would be able to use all 32 bits.

    If anyone has any bright ideas, including 'leave it alone', I'm all
    ears.

						-Matt






More information about the Kernel mailing list