linux-kernel - Re: [PATCH 5/7] vfs: Add wbcflush sysfs knob to disable storage device writeback cache flushes

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 30 Mar 2009 22:56:12 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Jens Axboe <jens.axboe@...cle.com>,
	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>, Christoph Hellwig <hch@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Theodore Tso <tytso@....edu>, Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Nick Piggin <npiggin@...e.de>, David Rees <drees76@...il.com>,
	Jesper Krogh <jesper@...gh.cc>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	chris.mason@...cle.com, david@...morbit.com, tj@...nel.org
Subject: Re: [PATCH 5/7] vfs: Add  wbcflush sysfs knob to disable storage device writeback cache flushes

On Monday 30 March 2009, Jeff Garzik wrote:
> Jens Axboe wrote:
> > On Mon, Mar 30 2009, Jeff Garzik wrote:
> >> Jens Axboe wrote:
> >>> On Mon, Mar 30 2009, Bartlomiej Zolnierkiewicz wrote:
> >>>> On Monday 30 March 2009, Fernando Luis Vázquez Cao wrote:
> >>>>> Add a sysfs knob to disable storage device writeback cache flushes.
> >>>> The horde of casual desktop users (with me included) would probably prefer
> >>>> having two settings -- one for filesystem barriers and one for fsync().
> >>>>
> >>>> IOW I prefer higher performance at the cost of risking losing few last
> >>>> seconds/minutes of work in case of crash / powerfailure but I would still
> >>>> like to have the filesystem in the consistent state after such accident.
> >>> The knob is meant to control whether we really need to send a flush to
> >>> the device or not, so it's an orthogonal issue to what you are talking
> >>> about. For battery backed caches, we never need to flush. This knob is
> >>> useful IFF we have devices with write back caches that STILL do a cache
> >>> flush.
> >> How do installers and/or kernels detect a battery-backed cache that does
> >> not need flush?
> > 
> > They obviously can't, otherwise it would not be an issue at all. And
> > whether it's an issue is up for debate, until someone can point at such
> > a device. You could add a white/blacklist.
> 
> Sorry, I guess I misinterpreted your dual "IFF" statement :)
> 
> I completely agree that the suggested knob, for disabling cache flush 
> for these battery-backed devices, is at the present time addressing an 
> entirely theoretical argument AFAICS.

Guys, please look at the patch in the context of whole patchset posted
not the current Linus' tree context only.

Patch #4 adds mandatory cache flush to fsync() (based on earlier Jeff's
submission I guess) and patch #5 (this patch) adds a knob to disable cache
flushing completely.

If patch #4 is going to be ever applied I want to have an option to disable
mandatory cache flushing on fsync() -- I don't need it and I don't want it
on my desktop (+ I somehow believe I'm not the only one).  OTOH I do need it
and I do want it on my server (+ to be on by default).

Actually legacy fsync() syscall is pretty bad interface in itself because:

	a) it is synchronous

	b) operates only on a single fd

and it encourages some pretty stupid (performance wise) usages like
calling fsync() after every mail fetched.  Adding mandatory cache flush
to it only makes things worse (again looking from performance POV).

BTW in Linux world we never made any guarantees for fsync() on devices
using write caching:

$ man fsync
...
       If  the  underlying  hard disk has write caching enabled, then the data
       may not really be on  permanent  storage  when  fsync()  /  fdatasync()
       return.
...

aio_fsync() looks a bit better on a paper but no filesystem implements
it currently...
--
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/