On 12/19/2011 11:16 PM, Christophe Varoqui wrote: > On lun., 2011-12-19 at 22:04 +0530, Chauhan, Vijay wrote: >> PERSISTENT RESERVE OUT/IN commands are currently not supported on mpath device. Any command sent to mpath device is routed to only one of the physical path (selected by path selector) from the active path group. PR OUT registration service action is one of the such use-case which fails as it expects all the physical path for the given mpath device to be registered. Due to these limitations, most of the cluster applications needs to manage persistent reservation through underlying physical path. >> > Persistent reservation is a path-centric command set. I don't see > clearly the benefit of folding (obfuscating?) it into the multipath > layer. > Agree. Persistent reservations is not something multipath should be handling internally. It'll just add functionality without any immediate gain. Plus we'd be incurring a support nightmare here. However, adding a _separate_ program for handling persistent reservations definitely would be a bonus, as this program could access multipath internals not otherwise accessible. And the integration into multipath doesn't gain us anything here; it's just used to figure out onto which paths PR should be updated. > Saving a few command lines ? I don't think there are wild admins playing > with PR without a clustering toolkit out there, so the tricky command > lines don't really matter. > Beg to disagree. 'Tricky command lines' are not the problem; figuring out multipath details (with the ever-changing output) definitely _is_. > I do maintain a clustering toolkit that handles PR, and I know this > feature would add code (multipath specific), not remove the current more > generic code. > > I also realize some other multipath implementations (PowerPath for one) > propose that feature. I'm curious to know the motivation. > > Am I the only one on the list thinking along this line ? Anyway, I have > no hard feelings against this work. > As did we, trying to implement a HA agent with persistent reservations :-) And hence I would definitely be glad having a tool setting persistent reservations on a multipathed device. Only I don't thing it should be built-into multipath itself. Much like kpartx: you definitely need the functionality, but this functionality doesn't need to be part of multipath proper. Other than that: good work. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
