Hello Jakob, Jakob Blomer: > Now, in our case the read-only branch is a Fuse network file system. > Reading a file (for copy-up) can involve downloading the file and > putting it in a local cache directory. If that local cache directory is > on the same file system as the writable branch, and if the Fuse file > system itself uses rename() in that cache directory, the procedure > deadlocks.
Let me make sure. If you try "mv /fuse/fileA /local/cache/fileA" then you will have deadlock? I mean, can you reproduce the problem without aufs? And does your Fuse network file system supports the consistency of the inode numbers? If not, it will bring a disaster into your aufs mount. > Attached there is a patch for aufs2.1-32 which is supposed to abort > rename() with EXDEV error whenever there is a copy-up from one directory > to another. For a reason I don't really understand, the deadlock does > not occur if the source and destination directory for the copy-up is the > same. In this case, lock_rename() acquires only one dir mutex. Is this the reason? > Perhaps the patch is useful to others. If the patch is obviously doing > something terribly wrong, I'd be glad to know. I cannot decide what is right or worng since it is highly depending upon your fuse network fs. Or is it very common to all fuse based fs? If not, it might be better add conditions as au_test_fuse() and new_test_for_subtype_of_fuse(). J. R. Okajima ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
