Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Jul 2005 23:55:17 +0200
From:      Matthias Buelow <mkb@incubus.de>
To:        Jon Dama <jd@ugcs.caltech.edu>
Cc:        freebsd-stable@freebsd.org, Matthias Buelow <mkb@incubus.de>, freebsd-questions@freebsd.org
Subject:   Re: dangerous situation with shutdown process 
Message-ID:  <200507142155.j6ELtHBp037282@drjekyll.mkbuelow.net>
In-Reply-To: Message from Jon Dama <jd@ugcs.caltech.edu> of "Thu, 14 Jul 2005 14:21:48 PDT." <Pine.LNX.4.53.0507141339170.536@spew.ugcs.caltech.edu> 

next in thread | previous in thread | raw e-mail | index | archive | help
Jon Dama <jd@ugcs.caltech.edu> writes:

>if the FUA bit in the sata command header is properly respected.
>if the flush cache command on an ata device is properly respected.
>if the flush cache command on an ata device is implemented (it's optional)
>if the flush cache command exists when the ata device was made (it isn't
>in the earlier versions of the ata spec).

or if the write-back cache can be disabled and re-enabled.

>anyways, your comments about softupdates needing total ordering versus
>journals needing partial ordering are wrong.  softupdates only requires
>that you do not call 'biodone(x)' until 'x' has been committed to disk.

Well. Can it group writes in such a way that flushing would be required
only at larger intervals, or can't it?

>this is 100% compatiable with the specification feature set, IF those
>semantics are actually present in the hardware.

Apparently it is not compatible with the real-world feature set and it
should've been clear to the designer(s) of softupdates that write-back
caches signal completion while the data is still in the cache. That's
the whole purpose of these mechanisms (so they can delay and reorder the
writes and write out whole tracks). You should only assume that, in that
case, a seperate flush command (or a workaround that amounts to a flush)
exists. Any different design assumes an oversimplified black box notion
of a drive that does not correspond with reality.

>please see the thread beginning with the following commit message for an
>extensive discussion of these topics:
>http://lists.freebsd.org/pipermail/cvs-src/2003-April/001002.html

I've seen nothing that contradicts what I've said.

The point is, that the request barrier design with flushing at barriers
as used in M$ Windows (and also completed in recent Linux kernels)
allows safe use of disks with write-back cache enabled, while FreeBSD
with softupdates apparently doesn't. I don't really care how it's
implemented, or if journalling is used, or softupdates, or a
quantum-tachyon-reverser mounted on the front antenna. I just want to
have the same level of data safety on my hardware with FreeBSD that I
would get with other systems.

mkb.



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