Re: [PATCH/RFC] Lustre VFS patch

[Jens Axboe]

On Tue, May 25 2004, braam wrote:
> Jens,
> 
> 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.

The generic_make_request() change itself is fine, as long as the proper
error is propagated back. I don't object to that at all, and I outlined
that to Phil last week as well. So in short:

        if (bio_data_dir(bio) == WRITE && bdev_read_only(bio->bi_bdev)) {
                bio_endio(bio, bio->bi_size, -EROFS);
                break;
        }

If you want to pass back 0 instead, then that would be a one-liner in
your (private) debugging patch. Ok?

> > And if this it to make sense for inclusion, io _must_ be 
> > ended with -EROFS or similar.
> > 
> > It seems to me that this probably belongs in your test 
> > harness for debugging purposes. At least in its current state 
> > it's not acceptable for inclusion.
> 
> This is, as I mentioned, only for testing.  It is, clearly, NOT ordinary
> system behavior at all since we don't, and won't, return the error. 
> 
> 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.

I don't think this change makes sense as written for the generic
kernels, not if you want to simply ignore the write. If that is the
case, it's a special case debug entry for a very narrow use (ie lustre).

-- 
Jens Axboe

-
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/