Hi Junjiro, thanks for the quick reply!
> 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. The fuse file system is based on the fuse low-level interface and it supports consistent inode numbers and hard links. The cache directory is something that is internally used by the fuse module. When you do "mv /fuse/fileA /some/other/place", the fuse module might not have cached /fuse/fileA yet (e.g. because it is accessed for the first time). It will then download the file from a remote server into a temporary location in, say, /var/lib/fs-cache/temp/fileA-PMxqGr. Once successfully downloaded, it uses rename() to atomically commit fileA into its final location /var/lib/fs-cache/fileA. This last rename() call can hang on the lock that aufs issues on the file system of the writable branch. > In this case, lock_rename() acquires only one dir mutex. Is this the > reason? Well, I can't exactly pinpoint it, but something in au_ren_lock() locks all further rename() calls across directories on the entire file system that hosts the writable branch. >> 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(). Thanks for the pointers to the test functions! I think the issue is specific to this particular fuse file system. Cheers, Jakob ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
