FFS data integrity

[Bob Johnson]

On 6/18/06, Pablo Marín Ramón <pabmara at fiv.upv.es> wrote:
> Bob Johnson wrote:
> > The short answer is that fsck can detect the bad inodes and fix or
> > delete them.  Assuming no programming errors, you don't have to worry
> > about a file containing bogus data after fsck has run.  Unfortunately,
> > if write-caching is enabled on your hard drive (and it probably is,
> > for speed), then the drive may internally re-order the writes and the
> > carefully crafted sequence of writes disappears, so there are no
> > guarantees (or at least, not as many).  Whether this is actually a
> > problem depends on the brand, model, and firmware version of the
> > drive, because some drives claim that data has been written to the
> > disk when it is actually only in the drive buffer, while other drives
> > are more honest.
>
[... removed for brevity...]
>
> The following is extracted from "Soft Updates: A Technique for
> Eliminating Most Synchronous Writes in the Fast Filesystem":

The first author on that paper, Marshall Kirk McKusick, was the
original developer of FreeBSD's filesystem, and of the softupdates
system, so I'm reasonably confident that if you trust the paper you
can trust the FreeBSD implementation (barring, as I said, programming
errors).

>
[...more deleted for brevity...]
>
> so I assume FreeBSD is doing the correct thing.
>
> Is correct this assumption?

It is supposed to be, but I've never looked at it in enough detail to
answer from my own knowledge.  The right people to ask would be Dr.
McKusick or a few of the other people who maintain that code.  There
is a mailing list specific to filesystem development:
freebsd-fs at freebsd.org. I think that for the level of detail you are
interested in, that would be a better place to ask than on this
general-purpose list. There are also other topic-specific lists
described at http://www.freebsd.org/handbook/eresources.html#ERESOURCES-MAIL,
you might find some of them of interest.

I hope that helps a little,

- Bob