Re: [PATCH/RFC] Lustre VFS patch

[Lars Marowsky-Bree]

On 2004-05-25T16:21:29,
   braam <braam@xxxxxxxxxxxxx> said:

> I think do answer your question:  ...
> > > If we were to return errors, (which, I agree, _seems_ much more
> > > sane, and we _did_ try that for a while!) then there is a good
> > > chance, namely immediately when something is flushed to disk, that
> > > the system will detect the errors and not continue to execute
> > > transactions making consistent testing of our replay mechanisms
> > > impossible.
> So: we can use the flags, but we cannot return the errors.

Maybe I am missing something here, but is this testing not somewhat
unrealistic then? In the general case, the system in production _will_
report an error and not silently throw away the writes.

> Some people find it very convenient to have this available, but if the
> opinion is that it is better to let development teams manage their own
> testing infrastructure that is acceptable to me.

Yes, this is very "convenient" and actually, "some people" think it is
absolutely mandatory that the kernel which is used for production sites
is 1:1 bit-wise identical than the one used for load & stress testing,
otherwise the testing is void to a certain degree...

Maybe you could fix this in the test harness / Lustre itself instead and
silently discard the writes internally if told so via an (internal)
option, instead of needing a change deeper down in the IO layer, or use
a DM target which can give you all the failure scenarios you need?

In particular the last one - a fault-injection DM target - seems like a
very valuable tool for testing in general, but the Lustre-internal
approach may be easier in the long run.


Sincerely,
    Lars Marowsky-Brée <lmb@xxxxxxx>

-- 
High Availability & Clustering	      \ ever tried. ever failed. no matter.
SUSE Labs			      | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ 	-- Samuel Beckett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/