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@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
