Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Device-mapper Development (http://www.linux-archive.org/device-mapper-development/)
-   -   'default' hardware handler for multipath (http://www.linux-archive.org/device-mapper-development/651837-default-hardware-handler-multipath.html)

Hannes Reinecke 04-02-2012 04:43 PM

'default' hardware handler for multipath
 
This patchset introduces a 'default' hardware handler for
dm-multipath.
Modern storage arrays typically support two failover methods,
the original proprietary and the modern ALUA-based one.
The device_handler implementation will currently select the
ALUA handler, and falling back to the proprietary one if
ALUA isn't supported.
However, in the built-in hardware table for multipath one
can specify only one hardware handler, causing the original
hardware handler to be overwritten.
By specifying a 'default' hardware handler multipath will not
try to attach a specific hardware handler, but rather using
the currently attached on.

Hannes Reinecke (2):
scsi_dh: Allow NULL hardware handler name in scsi_dh_attach()
dm-mpath: Allow 'default' hardware handler

drivers/md/dm-mpath.c | 8 ++++++--
drivers/scsi/device_handler/scsi_dh.c | 8 ++++++--
2 files changed, 12 insertions(+), 4 deletions(-)

--
1.7.7

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

"Moger, Babu" 04-03-2012 09:12 PM

'default' hardware handler for multipath
 
Thanks Hannes. We appreciate your work on this.

> -----Original Message-----
> From: dm-devel-bounces@redhat.com [mailto:dm-devel-
> bounces@redhat.com] On Behalf Of Hannes Reinecke
> Sent: Monday, April 02, 2012 11:44 AM
> To: linux-scsi@vger.kernel.org
> Cc: dm-devel@redhat.com; Mike Snitzer
> Subject: [dm-devel] [PATCH 0/2] 'default' hardware handler for multipath
>
> This patchset introduces a 'default' hardware handler for dm-multipath.
> Modern storage arrays typically support two failover methods, the original
> proprietary and the modern ALUA-based one.
> The device_handler implementation will currently select the ALUA handler,
> and falling back to the proprietary one if ALUA isn't supported.
> However, in the built-in hardware table for multipath one can specify only
> one hardware handler, causing the original hardware handler to be
> overwritten.
> By specifying a 'default' hardware handler multipath will not try to attach a
> specific hardware handler, but rather using the currently attached on.

I think we still have some issues here. Right now we load the driver
either by adding it in initrd or by using request_module call from device mapper.
If the user passes, hardware_handler "1 default" from multipath then request_module will fail.
How are we going to load the driver if these handlers are not loaded.

>
> Hannes Reinecke (2):
> scsi_dh: Allow NULL hardware handler name in scsi_dh_attach()
> dm-mpath: Allow 'default' hardware handler
>
> drivers/md/dm-mpath.c | 8 ++++++--
> drivers/scsi/device_handler/scsi_dh.c | 8 ++++++--
> 2 files changed, 12 insertions(+), 4 deletions(-)
>
> --
> 1.7.7
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Hannes Reinecke 04-18-2012 02:07 PM

'default' hardware handler for multipath
 
On 04/03/2012 11:12 PM, Moger, Babu wrote:
> Thanks Hannes. We appreciate your work on this.
>
>> -----Original Message-----
>> From: dm-devel-bounces@redhat.com [mailto:dm-devel-
>> bounces@redhat.com] On Behalf Of Hannes Reinecke
>> Sent: Monday, April 02, 2012 11:44 AM
>> To: linux-scsi@vger.kernel.org
>> Cc: dm-devel@redhat.com; Mike Snitzer
>> Subject: [dm-devel] [PATCH 0/2] 'default' hardware handler for multipath
>>
>> This patchset introduces a 'default' hardware handler for dm-multipath.
>> Modern storage arrays typically support two failover methods, the original
>> proprietary and the modern ALUA-based one.
>> The device_handler implementation will currently select the ALUA handler,
>> and falling back to the proprietary one if ALUA isn't supported.
>> However, in the built-in hardware table for multipath one can specify only
>> one hardware handler, causing the original hardware handler to be
>> overwritten.
>> By specifying a 'default' hardware handler multipath will not try to attach a
>> specific hardware handler, but rather using the currently attached on.
>
> I think we still have some issues here. Right now we load the driver
> either by adding it in initrd or by using request_module call from device mapper.
> If the user passes, hardware_handler "1 default" from multipath then request_module will fail.
> How are we going to load the driver if these handlers are not loaded.
>
The idea of the 'default' hardware handler is to avoid multipath
overriding the kernel matchine algorithm. To make this work we
obviously have to load the modules prior to start multipathing.

Given that we (ie RH and us) are already loading the device-handler
modules from the initrd independent from multipathing we should be fine.

But thinking a bit more about it, it might be better to handle this
via features.
Implementing a feature like 'default_hw_handler' would not override
the default hardware handler from the hardware table.
So the requested hardware handler would still be loaded, but the
actual initialisation would be controlled via the feature.

Yep, that sound better.
I'll be preparing a patch.

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)

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

"Moger, Babu" 04-18-2012 04:25 PM

'default' hardware handler for multipath
 
Hannes,

> -----Original Message-----
> From: Hannes Reinecke [mailto:hare@suse.de]
> Sent: Wednesday, April 18, 2012 9:08 AM
> To: Moger, Babu
> Cc: device-mapper development; linux-scsi@vger.kernel.org; Mike Snitzer
> Subject: Re: [dm-devel] [PATCH 0/2] 'default' hardware handler for multipath
>
> On 04/03/2012 11:12 PM, Moger, Babu wrote:
> > Thanks Hannes. We appreciate your work on this.
> >
> >> -----Original Message-----
> >> From: dm-devel-bounces@redhat.com [mailto:dm-devel-
> >> bounces@redhat.com] On Behalf Of Hannes Reinecke
> >> Sent: Monday, April 02, 2012 11:44 AM
> >> To: linux-scsi@vger.kernel.org
> >> Cc: dm-devel@redhat.com; Mike Snitzer
> >> Subject: [dm-devel] [PATCH 0/2] 'default' hardware handler for multipath
> >>
> >> This patchset introduces a 'default' hardware handler for dm-multipath.
> >> Modern storage arrays typically support two failover methods, the original
> >> proprietary and the modern ALUA-based one.
> >> The device_handler implementation will currently select the ALUA
> handler,
> >> and falling back to the proprietary one if ALUA isn't supported.
> >> However, in the built-in hardware table for multipath one can specify only
> >> one hardware handler, causing the original hardware handler to be
> >> overwritten.
> >> By specifying a 'default' hardware handler multipath will not try to attach a
> >> specific hardware handler, but rather using the currently attached on.
> >
> > I think we still have some issues here. Right now we load the driver
> > either by adding it in initrd or by using request_module call from device
> mapper.
> > If the user passes, hardware_handler "1 default" from multipath then
> request_module will fail.
> > How are we going to load the driver if these handlers are not loaded.
> >
> The idea of the 'default' hardware handler is to avoid multipath
> overriding the kernel matchine algorithm. To make this work we
> obviously have to load the modules prior to start multipathing.
>
> Given that we (ie RH and us) are already loading the device-handler
> modules from the initrd independent from multipathing we should be fine.
>
> But thinking a bit more about it, it might be better to handle this
> via features.
> Implementing a feature like 'default_hw_handler' would not override
> the default hardware handler from the hardware table.
> So the requested hardware handler would still be loaded, but the
> actual initialisation would be controlled via the feature.

hardware_handler is also used to pass on the arguments to handler. Like.
hardware_handler "2 emc 1"
We have to make sure that this feature does not break here. Considering all this
don't you think it may be better if we make this decision in multipath tools itself.
Common factor here is alua. It is always between alua or some other handler.
Does it make sense to check TPGS in tools?

> Yep, that sound better.
> I'll be preparing a patch.
>
> 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)

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


All times are GMT. The time now is 08:39 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.