Messages in this thread |  | | | Date | Tue, 25 May 2004 10:27:04 +0200 | | From | Jens Axboe <> | | Subject | Re: [PATCH/RFC] Lustre VFS patch |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |