linux-kernel - Re: PATCH reduce impact of FIFREEZE on userland processes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 10 Dec 2012 13:44:38 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Alun <auj@...penguin.org.uk>
Cc:	Alun <alun.linux@...penguin.org.uk>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: PATCH reduce impact of FIFREEZE on userland processes

On Sat, Dec 08, 2012 at 08:47:34AM +0000, Alun wrote:
> On Sat, 8 Dec 2012 12:20:29 +1100
> Dave Chinner <david@...morbit.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.

Irrecoverable in what way?

> 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.

Right - minimal effect, not "no effect".

> 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 have no doubt that you could write the 20 lines of C code needed
to use syncfs.... ;)

> 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!

Perhaps that tells you something - that both sides are telling you
it's a band aid for your specific issue? :/

fsfreeze is a data integrity operation and some people rely on it to
take immediate effect as it currently does. IMO, that's the bar that
the any generic freeze optimisation has to overcome.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/