Re: HAMMER filesystem update - design document

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Francois Tigeot wrote:
> On Wed, Oct 10, 2007 at 12:33:45PM -0700, Matthew Dillon wrote:
> >     Ok, here's the final design document that I am now implementing.
> >     Again, I expect most or all of these features to be ready and the
> >     filesystem to be beta-quality by the December release.
>
> Wow, this seems pretty good.
>
> What about data corruption issues ?
>
> Have you thought about implementing some sort of checksumming mechanism ?
>
> We cannot assume hardware to be absolutely reliable. There may be some
> silent corruption going on the disk or network layers, etc...
>
> More on this in this article:
> http://kerneltrap.org/Linux/Data_Errors_During_Drive_Communication

Quoting from Matt's announcement:

"    All information in a HAMMER filesystem is CRCd to detect corruption."

'All'

So the question - if there is one - is 'how good' that check is.

Otherwise, not the fs' job.

It *must* presume a 'generally reliable' environment beyond a certain point.

Error prevention, detection, (possible) correction, and friends more properly 
should exist in the storage hardware, I/O, and link layers.

As they do. Or do not.

. .. just as the article you cited points out.... hardware and driver selection 
issues, or even suboptimal silicon.


Bill