Re: [PATCH/RFC] Lustre VFS patch

From: Jens Axboe
Date: Tue May 25 2004 - 01:49:23 EST


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

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