: dangerous situation with shutdown process

[Jon Dama]

Well, maybe it is in't implemented properly--I can't exactly say--but the
blame should not fall on the method of data integrity used by softupdates.
Nor do I think softupdates would require per se more flushes.

Again, the blame would have to be on whoever is not taking the
measures necessary to ensure biodone() is called after the data is
properly committed.

The Request Barrier design only works if the answer to the IFs I asked are
"yes".  RB cannot solve an underlying failure of the hardware semantics.

There is an idea floating around that the question to those IFs is usually
"no".  If you feel that's wrong, please try to convince people here of
that fact.  Because if the answers are  "no" these issues are moot and
noone can or will do anything about it.

1a) If the ata driver is not flushing then there is a integrity problem in
    FreeBSD.
1b) If drives aren't respecting the flush there is no point in solving 1a.

2a) If the ata driver is flushing but doing so with every request, there
    is a potential performance problem.
2b) If the drives aren't respecting the flush there is no point solving
    2a.

There are of course other reasons to dislike the requirements softupdate
imposes on other aspects of the system.

I've CCed people who hopefully know more about the actual implementation
below softupdates than I do.

-Jon

> Jon Dama <jd at 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.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: empty
Type: application/octet-stream
Size: 0 bytes
Desc: 
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050714/ed9f2356/empty-0001.obj