[Lustre-discuss] [Lustre-devel] Integrity and corruption - can file systems be scalable?

[Nicolas Williams]

On Sat, Jul 03, 2010 at 09:18:47PM +0100, pg_lus at lus.for.sabi.co.UK wrote:
> [ ... ]
> > [ ... ] you can fsck each transaction discretely and
> > incrementally.  That means that you know exactly how much work
> > must be done to fsck a priori.  Sure, you still have to be
> > confident that N correct transactions == correct filesystem,
> > but that's much easier to be confident of than software
> > correctness.
> 
> That to me seems very naive like some old claims that journals
> obviate the need for 'fsck'.
> 
> Nothing can obviate the need for 'fsck', ad it is essentially an
> auditing tool; "proving" that a sequence of correct operations
> results in a correct outcome and thus no auditing is required,
> or is required only once, to me sounds extraordinarily
> unrealistic (and Peter Braam uses the killer argument of bugs,
> but that's not even the strongest), as it is based on this
> delusion:

Just because I didn't mention what ZFS calls "scrubbing" doesn't mean
that I think it's not desirable or not needed.  Indeed, ZFS can do
exactly what you suggest by "scrubbing" pools, a process that traverses
all meta-data and reads all data and verifies integrity, and which can
be done concurrently with normal filesystem operation.

However, scubbing is not "fsck" as we've always understood "fsck".  The
traditional "fsck" runs before you can mount a filesystem, and it reads
at least all meta-data.  That is either not feasible or not acceptable
today.  Scrubbing is.  As is incremental fsck.

Perhaps I misunderstood what Peter B. was getting at; perhaps Peter B.
was referring to "scrub" rather than "traditional fsck" and simply used
terminology that confused me.  Or perhaps you misunderstood what "fsck"
means to me.

> > [ ... ] Because only by making fscks incremental and discrete
> > can we get a handle on the amount of time that must be spent
> > waiting for fscks to complete.
> 
> Auditing of metadata cannot be incremental. I wonder how little
> real world experience backs this kind of delusion; in the real
> world existing, already checked metadata and data can be
> corrupted by faulty IO directed at other data and metadata.

I think it's much too early for you to speak of delusion on anyone's
part here.  Resorting to personal attacks is not exactly a good approach
to exchanging ideas.

Nico
--