[dm-devel] Re: [PATCH] Allow multipath devices to be created for readonly devices
Hannes Reinecke
hare at suse.de
Tue Jul 21 14:37:34 UTC 2009
Alasdair G Kergon wrote:
> On Wed, Jul 08, 2009 at 02:17:59PM +0530, Nikanth Karthikesan wrote:
>> Currently we cannot create device-mapper tables for multipath devices
>> whenever they are read-only.This patch modifies the device-mapper to
>> set the 'READ-ONLY' flag automatically whenever a read-only is added
>> to the table.
>
> I recall discussing this before:
>
> 1) Contrary to the assertion above, you can already create such dm
> tables, by marking them explicitly as read-only.
>
Yes, I know. The whole point of this patch is to make the interface
more userfriendly.
Or, push the implementation details down one layer into device-mapper.
Sure, it is possible to create read-only dm tables, but this requires
some prior knowledge as you have to set additional flags.
This patch actually got kicked off by a difference in behaviour
when try to mount read-only devices as read-write.
With 'normal' block devices you'll get an -EROFS, whereas on device-mapper
you get -ENXIO. The userland tools are normally equipped to handle the
former, not the latter.
The other part of the patch set links the read-only state of the device-mapper
device to the underlying devices, so when one is changed the others will
get updated, too.
> 2) The distinction between read-only and read-write device-mapper
> devices is currently clear and simple. This proposal replaces the
> definitions with far-less-intuitive ones and that is why I ignored it
> first time around.
>
> If you believe the existing interface and behaviour is inadequate,
> think about some alternatives:
> - What is the heart of the problem here? Give a specific example
> to show why we need improvements: Is the patch really about
> optimisation, arguing that to achieve the desired result through the
> current interface involves avoidable effort?
> - Consider whether adding another clearly-defined state to the system
> or extending the userspace interface would be a better approach.
>
The main point here is that by changing the device-mapper code we don't
have to modify any of the userland tools. Basically what this patches
do is moving the 'special device-mapper read-only handling code' from
userland into the device-mapper core.
Yes, this is debatable. But I don't know how many userspace tools there
are, and changing all of them to handle this case correctly is a daunting
task.
Plus that it'll be 'device-mapper only' code, which I don't think is a
good idea.
To summarise: I don't object to keeping the device-mapper interface fixed,
so that any program using libdevmapper or device-mapper directly has to be
aware of this.
What I do object to is that programs using generic means (ie syscalls)
should be changed to accomodate special device-mapper handling.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare at suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
More information about the dm-devel
mailing list