Jakob Blomer: > The fuse file system is based on the fuse low-level interface and it > supports consistent inode numbers and hard links.
It must be a good fuse-based fs. If I remember correctly, many fuse-based fs don't care about inum and hardlinks. > 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. I think I could see the scenario, and the reason why "new copyup x/6" series fixed the problem. By those patches, a long mutex lock held time on the parent dir was splitted into two shorter time. > > 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. Most of them are aufs spcific locks and are unreleated to the branch fs. One possible I can guess is s_vfs_rename_mutex in lock_rename. When the two parent dirs are same, lock_rename() doesn't acquire s_vfs_rename_mutex. > Thanks for the pointers to the test functions! I think the issue is > specific to this particular fuse file system. As you might know, - au_test_fuse() is defined in fs/aufs/fstype.h - you need to define new_test_for_subtype_of_fuse() by yourself. J. R. Okajima ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
