Alasdair G Kergon wrote:
On Fri, Apr 25, 2008 at 04:32:37PM +0200, Hannes Reinecke wrote:
this patch switches the device-mapper table to read-only
status automatically if one underlying device returns -EROFS.
I'm going to need some persuading here...
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@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
