> 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? Yes. > 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). I don't understand this issue. oh sorry, I'm not fs expert ;) -- 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
