From: Jens Axboe <axboe@suse.de>
To: braam <braam@clusterfs.com>
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 08:47:31 +0200 [thread overview]
Message-ID: <20040525064730.GB14792@suse.de> (raw)
In-Reply-To: <20040525014902.245C8310127@moraine.clusterfs.com>
On Tue, May 25 2004, braam wrote:
> Hi Jens,
>
> We use this patch on servers as follows.
>
> Lustre servers give an immediate response for RPC's to clients, and
> later indicate what transactions numbers have been committed to disk.
> At known points in the execution we sync all transactions to disk,
> execute our ioctl. When the ioctl is issues Lustre is also instructed
> not to send disk commit confirmation to clients. Then the system
> continues to execute some transactions, but only in memory, and send
> responses to clients. We are sure they are lost if we powercycle
> that system. This enables tests for replay of transactions by client
> nodes in the cluster.
>
> 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.
>
> I hope that this explains why we do not return errors. Now if you
> tell me that I can turn off I/O, and not get errors, with existing
> ioctls then I certainly should existing ioctls. Can you clarify that.
>
> Am I making sense to you now?
Not really, since you are not answering my question at all... My
question is not why you need this codeo or how you are using it, it's
why you cannot use existing functionality to do the same? Look at
genhd.c, it has functions for checking/marking/clearing read-only bit on
a block_device.
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.
--
Jens Axboe
next prev parent reply other threads:[~2004-05-25 6:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-24 11:39 [PATCH/RFC] Lustre VFS patch Peter J. Braam
2004-05-24 11:46 ` Jens Axboe
2004-05-25 1:48 ` braam
2004-05-25 6:47 ` Jens Axboe [this message]
2004-05-25 8:21 ` braam
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=20040525064730.GB14792@suse.de \
--to=axboe@suse.de \
--cc=akpm@osdl.org \
--cc=braam@clusterfs.com \
--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