On Wed, Dec 05, 2012 at 09:17:07PM +0000, Alun wrote: > > This patch is against kernel version 3.7-rc7. > > The FIFREEZE ioctl blocks userland writes, then calls sync_filesystem. > If there is a large amount of dirty data, this sync can take a > substantial time to complete, with corresponding loss of responsiveness > to any userland processes wishing to write. > > This patch simply adds an extra call to sync_filesystem prior to > blocking writes, so that (hopefully) the majority of outstanding dirty > data has been flushed before we impact on userland. The problem wth doing this is that the sync can delay the freeze process by quite some time under the exact conditions you describe. If you want freeze to take effect immediately (i.e instantly stop new modifications), then adding a sync will break this semantic. THere are existing users of freeze that require this behaviour... > I'm a complete kernel newbie and have only done some pretty minimal > testing on my own machine, but with the patch in place the impact of > running "fsfreeze -f" immediately followed by "fsfreeze -u" on a > moderately loaded filesystem (as measured by time taken for a write() > to complete) was reduced from 2.5 to 0.2 seconds. That, to me, is irrelevant, because something is normally done while the filesystem is frozen. It's not uncommon for freeze periods to extend to minutes while work is done by whatever required the freeze. Hence the few seconds it takes to acheive the frozen state is mostly irrelevant. If you are really concerned by minimising the amount of time it takes to freeze, then "syncfs; fsfreeze -f; fsfreeze -u" will get you exactly the same result as your patch, without having any bad side effects for other users.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
