mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "braam" <braam@clusterfs.com>
To: "'Jens Axboe'" <axboe@suse.de>
Cc: <torvalds@osdl.org>, <akpm@osdl.org>,
	<linux-kernel@vger.kernel.org>,
	"'Phil Schwan'" <phil@clusterfs.com>
Subject: RE: [PATCH/RFC] Lustre VFS patch
Date: Tue, 25 May 2004 16:21:29 +0800	[thread overview]
Message-ID: <20040525082305.BAEE93101A0@moraine.clusterfs.com> (raw)
In-Reply-To: <20040525064730.GB14792@suse.de>

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.

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

- Peter -




  reply	other threads:[~2004-05-25  8:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-24 11:39 Peter J. Braam
2004-05-24 11:46 ` Jens Axboe
2004-05-25  1:48   ` braam
2004-05-25  6:47     ` Jens Axboe
2004-05-25  8:21       ` braam [this message]
2004-05-25  8:27         ` Jens Axboe
2004-05-25 10:52         ` Lars Marowsky-Bree
2004-05-25 11:45           ` braam
2004-05-25 13:35           ` Kevin Corry
2004-05-25 13:55             ` Jens Axboe
2004-05-24 12:00 ` hch
2004-05-24 12:01 ` hch
2004-05-24 12:03 ` hch
2004-05-24 15:33   ` Horst von Brand
2004-05-25 20:43     ` hch
2004-05-24 12:05 ` hch
2004-05-24 18:06   ` Trond Myklebust
2004-05-25  8:21     ` braam
2004-05-24 12:08 ` hch
2004-05-24 13:44   ` Arjan van de Ven
2004-05-24 13:53     ` viro
2004-05-28 16:56     ` braam
2004-05-28 17:00       ` Christoph Hellwig
2004-05-24 14:19 ` viro
2004-05-28 23:18 ` Maneesh Soni
2004-05-29 17:53 ` Anton Blanchard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040525082305.BAEE93101A0@moraine.clusterfs.com \
    --to=braam@clusterfs.com \
    --cc=akpm@osdl.org \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phil@clusterfs.com \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®