Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 May 2004 10:40:20 +0800
From:      Xin LI <delphij@frontfree.net>
To:        Gary Corcoran <garycor@comcast.net>
Cc:        Julian Elischer <julian@elischer.org>
Subject:   Re: QMail and SoftUpdates
Message-ID:  <20040518024020.GA631@frontfree.net>
In-Reply-To: <40A974DA.30704@comcast.net>
References:  <20040517174836.GA983@frontfree.net> <Pine.BSF.4.21.0405171323010.27448-100000@InterJet.elischer.org> <20040518021433.GA969@frontfree.net> <40A974DA.30704@comcast.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 17, 2004 at 10:28:42PM -0400, Gary Corcoran wrote:
> Xin LI wrote:
[snip]
> >doing fsync(), because with ATA hardware writing cache, the disk will
> >"cheat" the opearting system - Before the data actually goes to disk,
> >it tells that it is, and data is lost if crash occours here.
>                                            ^^^^^
> Umm - shouldn't it be only if *power loss* occurs here?
> Even if the OS crashes, as long as power is supplied to the drive,
> its firmware should finish writing the data from its cache to the
> disk media, no?  And therefore, as long as one has a stable power
> source, e.g. running off a UPS, there really isn't any great risk
> from on-drive write caches, is there?

I don't think so. Personally I think it is still danger if a crash
occours. Soft Updates rolls back buffers when necessary to guarantee
the on-disk state is in a "recoverable consistency". With a drive
cheating the operating system and reorder operating system write
operations, there is a potential risk that, when operating system
"thinks" that "this order is good and won't cause any problem", the
disk "thinks" that "that order is better and I write in that order",
and an "unexpected SoftUpdates inconsistency" occours. This is very
likely to cause data loss, or even more worse problem because there
might be wild pointers in i-nodes, or used blocks that are not marked
"used" in the cylgroup bitmap.

Cheers,
--=20
Xin LI <delphij frontfree net>	http://www.delphij.net/
See complete headers for GPG key and other information.


--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAqXeUOfuToMruuMARAjgqAJ90DK7u2CEeRi8ji3hGwWiOGR1XHQCfbaXk
iLWHLLhAuaz4Rn5ja0IByYA=
=o3IG
-----END PGP SIGNATURE-----

--VS++wcV0S1rZb1Fb--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040518024020.GA631>