On Fri, Apr 24, 2009 at 03:02:01PM -0400, Christoph Hellwig wrote: > On Fri, Apr 24, 2009 at 07:55:24PM +0100, Al Viro wrote: > > Nah, it's not that. I can hold that in a separate branch and keep it > > anchored. The question is, what else will end up there? > > * the work inside the methods on BKL _removal_ > > * things like merging that ->write_super() call into ->put_super(), > > etc. > > * probably parts of work on s_flags mess and ro (tied to remout) > > * moving lock_super from callers into ->write_super and > ->remount_fs. No need to only push one lock down when we > touch them anyway. Aye. We want lock_super() dead anyway, and the most obvious way to do that is to shove it down to filesystems and let them kill it one by one. We might want to switch sync_supers() et.al. to down_write() and do similar thing in callers of fsync_super/__fsync_super() (i.e. instead of get_super() use a variant that would lock for write), while we are at it; OTOH, that'll need careful thinking about - things like shrink_dcache() currently don't care about write_super done in parallel and we might add contention where it hurts. It's worth investigating, though - switching s_umount to mutex is attractive per se and we might simplify locking e.g. in freeze/thaw on that. -- 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
