Re: [RFC][PATCH 0/3] persistent management feature for multipath-tools

[Hannes Reinecke <hare@suse.de>]

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@suse.de			      +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)