KOSAKI Motohiro wrote: >>> 2. this logic kill multi thread application. >>> >>> this logic mean mmap_sem grabbing until unfreeze. >>> it mean othrer thread in the same process can't page-fault although >>> it don't touch frozen-sb. >>> it seems strange. >> Hm, I hadn't thought about this ... On the one hand, ->page_mkwrite can >> already sleep, though a userspace freeze/unfreeze could potentially take >> much much longer. freeze/unfreeze *should* happen very quickly, but >> nothing enforces that. >> >> Do you have any suggestions? > > One more comment. > > I read ioctl_fsfreeze() and freeze_bdev(), it call __fsync_super(). > Oh, I don't think __fsync_suepr is very quick. Well, what I mean is that the filesystem is not intended to be frozen for long periods of time. But it's not enforced by any method. > So, page-fault have one unique characteristics. > if page-fault return 0 without pte change, page-fault is occur again soon. > then, if you need long time waiting, I think you can use following technique. > > unlock mmap_sem > wait long-time > lock mmap_sem > goto out; > > > it cause page-fault counter increment twice unintesionally. > but no problem. fs-freeze is not freqently event. > > Am I missing anything? Hm, I'll have to think about that. This is not my best area. :) So do you mean that if a wait needs to happen for the frozen fs, we can unlock, do that wait for unfreeze, relock, return early, and come back again when it is not frozen? One other thing that I think I just discovered is that nothing is actually stopping mmap IO even on a frozen filesystem, as long as no metadata updates are required for the IO... I'm seeing this on xfs anyway (ext4 tries to update mtime, so that gets stopped on the frozen fs). Thanks, -Eric -- 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
