I agree with Hannes, that we should allow multipath to override the
default attachment, mainly to give control to the user.
But, I have a small issue with the attached patch. See below.
On Wed, 2009-04-22 at 11:16 +0200, Hannes Reinecke wrote:
> Hi Mike,
>
<snip>
> diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
> index 095f77b..46d01d9 100644
> --- a/drivers/md/dm-mpath.c
> +++ b/drivers/md/dm-mpath.c
> @@ -592,12 +592,25 @@ static struct pgpath *parse_path(struct arg_set
> *as, struct path_selector *ps,
> }
>
> if (m->hw_handler_name) {
> - r = scsi_dh_attach(bdev_get_queue(p->path.dev->bdev),
> - m->hw_handler_name);
> + struct request_queue *q = bdev_get_queue(p->path.dev->bdev);
> +
> + r = scsi_dh_attach(q, m->hw_handler_name);
> + if (r == -EBUSY) {
> + /*
> + * Already attached to different hw_handler,
> + * try to reattach with correct one.
> + */
> + scsi_dh_detach(q);
> + r = scsi_dh_attach(q, m->hw_handler_name);
> + }
> if (r < 0) {
> + ti->error = "error attaching hardware handler";
> dm_put_device(ti, p->path.dev);
> goto bad;
> }
> + } else {
> + /* Play safe and detach hardware handler */
> + scsi_dh_detach(bdev_get_queue(p->path.dev->bdev));
> }
I prefer not to detach a previously attached hardware handler, if
multipath doesn't have any handler associated with the device. Leaving
it will not do any hard to multipath as the multipath layer would not
call scsi_dh_activate for the device.
Device handler would just handle the sense code as defined in the
kernel.
>
> r = ps->type->add_path(ps, &p->path, as->argc, as->argv,
> &ti->error);
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
