• Jakob Unterwurzacher's avatar
    fs: split inode number tracking and kernel nodeid tracking · 1d0096e5
    Jakob Unterwurzacher authored
    Using the inode numbers as the nodeid causes problems
    when the fs reuses inode numbers. This is the case with
    any overlay filesystem that is backed by ext4 like the
    loopback example or gocryptfs.
    
    We already had the expSleep() and re-add hack,
    
    	7090b027 fs: wait out apparent inode type change
    	68f70527 fs: addNewChild(): handle concurrent FORGETs
    
    to mitigate some of the problems (at the risk of deadlocking
    forever), but I could not find a way to work around the following
    case uncovered by fsstress:
    
    The kernel expects a fresh nodeid from MKDIR (see #372 for a
    debug log).
    
    This is now guaranteed by passing the O_EXCL to addNewChild().
    However, this also means that the hard link detection must
    happen in addNewChild() as opposed to newInodeUnlocked()
    before. The expSleep and re-add hacks are no longer needed
    and have been dropped.
    
    This survived 24 hours (42587 iterations) of fsstress testing.
    Tested was the loopback example running on top of ext4 on
    Linux 5.8.10.
    
    Fixes https://github.com/hanwen/go-fuse/issues/372 .
    
    v2: Rename inoMap -> stableAttrs, nodeidMap -> kernelNodeIds
        acc. to feedback from Han-Wen.
    v3: initialize Inode.nodeId early
    v4: drop leftover file stash.txt
    
    Change-Id: Ibb36a886f15d48727daa10b9717ea88e45a6b8af
    1d0096e5
inode.go 20.5 KB