On Thu, Dec 16 2010 at 2:32am -0500,
Menny_Hamburger@xxxxxxxx <Menny_Hamburger@xxxxxxxx> wrote:
> Hi Mike,
>
> I am sorry about the submission problems, there's a first time for everything...
>
> I know this sounds superstitious but I did run quite thorough tests on
> this issue and I would really prefer that the proposed patch would go
> through the same code path as the one I have tested.
>
> My suggestion is to modify the scsi_dh code as follows:
>
> if (!scsi_dh || !get_device(&sdev->sdev_gendev) ||
> sdev->sdev_state == SDEV_CANCEL ||
> sdev->sdev_state == SDEV_DEL)
> err = SCSI_DH_NOSYS;
>
> if (sdev->sdev_state == SDEV_OFFLINE)
> err = SCSI_DH_DEV_OFFLINED;
>
> if (err) {
> if (fn)
> fn(fn_data, err);
>
> return err;
> }
>
> There is logic and benefits here:
> 1) SDEV_CANCEL/SDEV_DEV are just a stage before the DH is deleted so we can respond with the same SCSI_DH_NOSYS.
> I think it's best here to handle these together, since they are in fact the same thing.
> In addition, when we delete a device, I don't think it goes through an offline state.
> 2) SDEV_OFFLINE is easily reverted by echoing to the state of the device - it's not like detaching.
> Returning SCSI_DH_DEV_OFFLINED will just call the default case and perform fail_path - no need to worry about any handler issues here.
> 3) It will let me sleep better at night...
I think you misunderstood me.
We had a bugzilla exchange yesterday (and as you stated above): the
dm-mpath change isn't required so it is only the scsi_dh patch that
needs to go upstream.
I didn't take issue with your scsi_dh patch. What I shared (below) was
that dm-devel isn't the appropriate place to email a patch that is
exclussively for scsi_dh. (This is just the tedious bit of "how does
this change go upstream?").
I'll take care of rebasing your scsi_dh patch to the scsi-misc git tree
I referenced and then send the patch to linux-scsi on your behalf.
Regards,
Mike
> -----Original Message-----
> From: Mike Snitzer [mailto:snitzer@xxxxxxxxxx]
> Sent: 15 December, 2010 18:10
> To: Hamburger, Menny
> Cc: dm-devel@xxxxxxxxxx
> Subject: Re: [Patch 2 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
>
> On Wed, Dec 15 2010 at 3:31am -0500,
> Menny_Hamburger@xxxxxxxx <Menny_Hamburger@xxxxxxxx> wrote:
>
> > The problem:
> > When a SCSI device attached to a device handler is deleted, userland processes currently performing I/O on the device will I/O hang forever.
> >
> > Attached is the multipath layer part of the patch.
>
> Please do not use attachments when submitting patches. Please inline
> the patch in the body of the mail. Also please trim extraneous info
> when you reply to mails and please do not top-post.
>
> Your patch submissions were not well received by the dm-devel patchwork
> (which automatically collects submitted dm-devel patches so they don't
> get lost in the shuffle).
>
> Also, please use unique and descriptive subjects for the patches in a
> multipatch series.
>
> As for the proposed mpath change: Babu already pointed out that you
> don't need this mpath change as the default case already performs
> fail_path().
>
> So all you need is that scsi_dh patch to get upstream. But to do that
> you'll need to:
> 1) create a patch against the upstream scsi-misc tree (not RHEL5.5):
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
>
> 2) send the patch to the linux-scsi@xxxxxxxxxxxxxxx mailing list (feel
> free to cc dm-devel too).
>
> Once this change is in the upstream scsi tree it'll propagate to RHEL
> releases.
>
> Thanks,
> Mike
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
