Re: PATCH reduce impact of FIFREEZE on userland processes

[Alun <auj@ty-penguin.org.uk>]

On Sat, 8 Dec 2012 12:20:29 +1100
Dave Chinner <david@fromorbit.com> wrote:

First off, thanks for the examples. I'll answer your one question and
then I'll shut up!

> > I'll try and chase this up by submitting patches to lvcreate and
> > fsfreeze (in the former case, I think there's no reason not to run
> > syncfs; in the latter perhaps it should be a command line option).
> 
> Is that even necesary? users can issue the sync themselves if
> necessary....

I think it's necessary for the issue to be better documented in LVM at
the very least. I've dabbled with LVM for nearly 10 years, and used it
in a busy production environment for around 6. For nearly 2 years I've
been seeing, every now and then, these odd cases where taking a snapshot
caused irrecoverable high load on the server. I've never seen any
mention anywhere of the advisability of manually running sync prior to
taking a snapshot on a busy system, and I had to get down to looking at
the kernel sources before I got an inkling this might be the issue. I'd
imagine that the vast majority of end users think the same way as I
did, viz that taking a snapshot was designed to have minimal effect on
any other users of the filesystem.

There's also the issue that AFAIK there's no commonly distributed
program which will allow you to call syncfs() on a filesystem. Running
sync is a bit of a sledgehammer approach for a busy system with
multiple large filesystems.

I've submitted a patch to util-linux, adding a --sync option to
fsfreeze which, if specified, will syncfs the requested filesystem
prior to any freeze operation. Hopefully they'll accept this, though
the only comment I've received so far suggested that I should be
submitting a kernel patch rather than band aiding it in userland!

Looking at the LVM sources, it would appear that the freezing of 
affected filesystems is done in the kernel side of device mapper. I'm
not going there!

Anyway, thanks for your time.

Cheers,
Alun.