Le mardi 20 mai 2008 à 15:48 +0100, Alasdair G Kergon a écrit : > On Fri, May 16, 2008 at 09:35:44PM +0200, christophe varoqui wrote: > > fact: device-mapper refuse to load a RW multipath table on these paths > > (ie without libdevmapper:set_task_set_ro()) > > question: should change this behaviour to allow to load a RW multipath > > table on these paths and let the IO be failed by the storage hardware ? > > Yes. But relax this *only* for multipath targets, where the whole idea > is to "hide" path problems from the layer above. Fair enough. > It would not make sense > in my view to do this for other DM targets. > During my testing I remember seeing a RW linear map loaded over a RO multipath map (through a genuine vgchange -ay, the PV being the multipath). > > Alasdair proposed to add more explicit table loading ioctl return code > > when the failure is due to this ready-only paths issue (E_ROFS for > > example). > > I think this should be done too (for non-multipath and other errors). > Right, I'm about the publish a changeset for supporting the whole RO notion in the multipath-tools : 1/ printing the RO/RW information 2/ fallbacking to RO when RW loading fails 3/ new flag to force map reloading, which takes care of the RO->RW promotion and RW->RO demotion scenarii I'll adapt 2/ to your new return codes when available. Thanks for caring, cvaroqui -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
