All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Varoqui <christophe.varoqui@free.fr>
To: sekharan@us.ibm.com
Cc: jens.axboe@oracle.com, james.bottomley@hansenpartnership.com,
	agk@redhat.com, linux-scsi@vger.kernel.org, dm-devel@redhat.com
Subject: Re: [BUG] dm-mpath and scsi persistent reservation
Date: Thu, 23 Oct 2008 21:30:26 +0200	[thread overview]
Message-ID: <20081023213026.709f9531@plop> (raw)
In-Reply-To: <1224710517.14830.852.camel@chandra-ubuntu>

Le Wed, 22 Oct 2008 14:21:57 -0700,
Chandra Seetharaman <sekharan@us.ibm.com> a écrit :

> 
> On Wed, 2008-10-22 at 21:54 +0200, Christophe Varoqui wrote:
> > It seems to me the device handler infrastructure proposes to
> > translate scsi error codes from requests generated by the device
> > handler itself. I
> 
> No, the handler doesn't generate the requests.
> 
> Device handler's check_sense() function is called from the
> scsi_error.c:scsi_check_sense() function whenever a sense code is
> returned from the device (on normal I/Os).
> 
> When in the sense function, the device handler can do any action (like
> closing the other path(s)) and returning an appropriate error code
> (such that dm doesn't retry the I/O on other paths).
> 
Thanks for the clarification. I shouldn't have stopped after
reading the hp_sw handler, which does not implement a .check_sense

So now, device handlers indeed look promising. I still see difficulties
though :
1/ reservation conflict is a scmd status, and as such short-cuts the
scsi_check_sense function altogether. Sould we hook device handlers to
status parser too ?
2/ should we create an trivial device handler and load multi-handlers
multipath maps or should we make this device handler implicitly always
active ?

Regards,
cvaroqui
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2008-10-23 19:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-21 21:19 [BUG] dm-mpath and scsi persistent reservation Christophe Varoqui
2008-10-21 22:48 ` Chandra Seetharaman
2008-10-22 19:54   ` Christophe Varoqui
2008-10-22 20:30     ` [dm-devel] " James Bottomley
2008-10-23  2:53       ` Mike Christie
2008-10-22 21:21     ` Chandra Seetharaman
2008-10-23 19:30       ` Christophe Varoqui [this message]
2008-10-23 21:03   ` Christophe Varoqui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081023213026.709f9531@plop \
    --to=christophe.varoqui@free.fr \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sekharan@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.