Re: PATCH reduce impact of FIFREEZE on userland processes

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com