fs: split inode number tracking and kernel nodeid tracking
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
Showing
Please register or sign in to comment