Alasdair G Kergon wrote:
On Fri, Apr 25, 2008 at 04:32:37PM +0200, Hannes Reinecke wrote:I'm going to need some persuading here...this patch switches the device-mapper table to read-only status automatically if one underlying device returns -EROFS.An analogy. If I call open() with O_RDWR and but that can't be done because the device is read-only - what happens? Does the open() silently give me a read-only file descriptor instead? Or does it give me -EROFS? If I request DM_TABLE_LOAD without the DM_READONLY_FLAG, I am asking for a device I can write to and if that's not possible I expect an error. If I'd wanted a read-only device I'd have set the DM_READONLY_FLAG on my request. Is the real problem that -EROFS/-ENXIO errors are not propagating back up through target _ctr functions as perhaps they should?
No, the real error is that you currently cannot create multipath targets on devices exported as read-only from the storage. Having device-mapper setting the 'read-only' flag automatically on those devices instead of just bailing out will fix this. The main problem we're facing here (from the point of multipathd) is the lack of error reporting from device-mapper. We're just getting the very helpful error 'ioctl failed', with no indication about _why_. So we have no clue at all that we might have to check for the read-only setting on this device. And checking this setting on _any_ ioctl error is just plain silly. The rest of the patch (calling _set_disk_ro and refusing to open the device with O_RDWR) is just whitewhash to get a better user experience. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare suse de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg)