In message <20080424134826.GD15214@xxxxxxxxxxxxxxxxxx>, Al Viro writes: > On Thu, Apr 24, 2008 at 03:05:21PM +0200, Miklos Szeredi wrote: [...] > And yes, we need the counterpart for superblock-level stuff, to deal with > remaining races (look at fs_may_remount_ro() and puke - it's still racy > as hell). E.g. unlink should do sb-level "will write" when it drops > i_nlink to 0 and final removal of inode should do "won't write". Al, any near-term plans for sb-level "want write" locking as we discussed briefly at LSF? Being able to do so for copyup in unionfs will hopefully allow me to prevent concurrent topology changes. And while we're digressing. It appears to me that when someone wants to change a single meta-data item in a f/s, then locking rules are simple: e.g., lock the directory inode. But when you want to modify more than one, you need a different kind of lock -- hence the s_vfs_rename_mutex. The latter requires calling lock_rename to find the lowest common ancestor of the two directories that need locking. This rename-locking protocol appears to be a special case of the sb-level "want write" idea, right? Moreover, I don't believe that cross-directory renames are that common, so replacing the s_vfs_rename_mutex and its use with a more generic sb-level multi-operation write-lock should have a negligible performance impact. Thanks, Erez. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
