linux-kernel - Re: [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck)

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20080117205451.GB2065@elf.ucw.cz>
Date:	Thu, 17 Jan 2008 21:54:51 +0100
From:	Pavel Machek <pavel@...e.cz>
To:	Chris Mason <chris.mason@...cle.com>
Cc:	Daniel Phillips <phillips@...gle.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Chinner <dgc@....com>, Theodore Tso <tytso@....edu>,
	Al Boldi <a1426z@...ab.com>,
	Valerie Henson <val.henson@...il.com>,
	Rik van Riel <riel@...hat.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [Patch] document ext3 requirements (was Re: [RFD] Incremental
	fsck)

On Tue 2008-01-15 20:36:16, Chris Mason wrote:
> On Tue, 15 Jan 2008 20:24:27 -0500
> "Daniel Phillips" <phillips@...gle.com> wrote:
> 
> > On Jan 15, 2008 7:15 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> > > > Writeback cache on disk in iteself is not bad, it only gets bad
> > > > if the disk is not engineered to save all its dirty cache on
> > > > power loss, using the disk motor as a generator or alternatively
> > > > a small battery. It would be awfully nice to know which brands
> > > > fail here, if any, because writeback cache is a big performance
> > > > booster.
> > >
> > > AFAIK no drive saves the cache. The worst case cache flush for
> > > drives is several seconds with no retries and a couple of minutes
> > > if something really bad happens.
> > >
> > > This is why the kernel has some knowledge of barriers and uses them
> > > to issue flushes when needed.
> > 
> > Indeed, you are right, which is supported by actual measurements:
> > 
> >     http://sr5tech.com/write_back_cache_experiments.htm
> > 
> > Sorry for implying that anybody has engineered a drive that can do
> > such a nice thing with writeback cache.
> > 
> > The "disk motor as a generator" tale may not be purely folklore.  When
> > an IDE drive is not in writeback mode, something special needs to done
> > to ensure the last write to media is not a scribble.
> > 
> > A small UPS can make writeback mode actually reliable, provided the
> > system is smart enough to take the drives out of writeback mode when
> > the line power is off.
> 
> We've had mount -o barrier=1 for ext3 for a while now, it makes
> writeback caching safe.  XFS has this on by default, as does reiserfs.

Maybe ext3 should do barriers by default? Having ext3 in "lets corrupt
data by default"... seems like bad idea.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/