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>