On Thu, Mar 29, 2012 at 2:11 PM, Jan Kara <jack@xxxxxxx> wrote: > On Thu 29-03-12 12:19:43, Szeredi Miklos wrote: >> On Thu, Mar 29, 2012 at 1:43 AM, Jan Kara <jack@xxxxxxx> wrote: >> > Most of places where we want freeze protection coincides with the places where >> > we also have remount-ro protection. So make mnt_want_write() and >> > mnt_drop_write() (and their _file alternative) prevent freezing as well. >> > For the few cases that are really interested only in remount-ro protection >> > provide new function variants. >> >> The underlying mechanism of mnt_want_write() and sb_start_write() is >> basically the same: >> >> - increment per-CPU counter >> - mb >> - check flag >> - retry loop for races > Well, __mnt_want_write() has the special handling of MNT_WRITE_HOLD. > Otherwise yes, the locking logic is rather similar. > >> It is scalable but still there is a non-zero overhead, and duplicating >> it doesn't seem to make a lot of sense. Why not instead try to use a >> common abstraction for both? > I'm not sure here. Are you concerned about performance - i.e. you would > like to merge the remount-ro counter and topmost anti-freeze counter? Yes. > That > cannot work because in some cases you want remount-ro protection but not > freezing protection. In particular when you have file open for writing, > you want to refuse remount-ro but still allow freezing. Well, you could have a separate counter that keeps track of the difference, which just needs to be modified when the two counters diverge (i.e. when opening a file for write and when releasing that file). But yeah, it may not be worth it. Thanks, Miklos -- 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
