linux-ext4 - Re: Mentor for a GSoC application wanted (Online ext2/3 filesystem checker)

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]

Date:	Tue, 22 Apr 2008 15:48:51 +0100
From:	Jamie Lokier <jamie@...reable.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	"Ricardo M. Correia" <Ricardo.M.Correia@....COM>,
	Theodore Tso <tytso@....edu>,
	Eric Sandeen <sandeen@...hat.com>,
	Alexey Zaytsev <alexey.zaytsev@...il.com>,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	Rik van Riel <riel@...riel.com>
Subject: Re: Mentor for a GSoC application wanted (Online ext2/3 filesystem checker)

Andi Kleen wrote:
> > Is there a reason why this isn't being done other than performance?
> 
> One reason against it is that in many (but not all) setups to guarantee
> reaching the platter you have to disable the write cache, and at least
> for consumer level hard disks disk vendors generally do not recommend
> doing this because it significantly lowers the MTBF of the disk.

I think the MTBF argument is a bit spurious, because guaranteeing it
reaches the platter with all modern disks is possible, with the
appropriate kernel changes, and does not require the write cache to be
disabled.

TBH, I think the reason is it's simply never been implemented.  There
are other strategies for mitigating data loss, after all, and
filesystem structure is not at risk; barriers are fine for that.

Right now, you have the choice of 'disable write cache' or 'fsync
flushes sometimes but not always, depending on lots of factors'.

The option 'fsync flushes always, write cache enabled' isn't
implemented, though most hardware supports it.

Btw, on Darwin (Mac OS X) it _is_ because of performance that fsync()
doesn't issue a flush to platter.  It has an fcntl(F_FULLSYNC) which
is documented to do the latter.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html