From: Heinz.Mauelshagen@t-online.de (Heinz J . Mauelshagen)
To: James Bottomley <James.Bottomley@steeleye.com>
Cc: mauelshagen@sistina.com, christophe.varoqui@free.fr,
mge@sistina.com, SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [lvm] [christophe.varoqui@free.fr: dm multipath target]
Date: Tue, 19 Aug 2003 18:09:48 +0200 [thread overview]
Message-ID: <20030819180948.N8420@sistina.com> (raw)
In-Reply-To: <1061302795.2134.7.camel@fuzzy>; from James.Bottomley@steeleye.com on Tue, Aug 19, 2003 at 09:19:53AM -0500
On Tue, Aug 19, 2003 at 09:19:53AM -0500, James Bottomley wrote:
> On Tue, 2003-08-19 at 04:51, Heinz J . Mauelshagen wrote:
> > On Tue, Aug 19, 2003 at 11:04:31AM +0200, christophe.varoqui@free.fr wrote:
> > No, device-mapper is designed completely generic (LVM2 as well BTW).
> > It will never contain any vendor specific hacks.
>
> We don't need it to contain any vendor code, but we do need an interface
> for vendor specific additions.
In case there's no more you need than the given target methods in
device-mapper (e.g. mapping and endio methods), you've got it already :)
>
> How arrays accomplish a path switch is highly vendor specific. Some
> (like EMC) run all paths active, so nothing needs doing. Others need a
> specific command sent to the array down the path before the switch can
> be done.
I know and those private policies should not be addressed
in device-mapper but much rather in userspace so that there's accessible
paths once mapping tables are activated.
>
> > Ghosts should report EIO in case of an unstarted LUN anyway ?
> > In case they are started they are supposed to report EPERM on IO because
> > they don't support any.
>
> This is awfully vendor specific again. I know, for example, the HP MSA
> array will report a check condition, not ready. I think we translate
> this to I/O error in the mid-layer (best we can do).
Ok, fair enough. We know that we need better error reporting and
handling in 2.7.
Plus we need some decent "basic" error reported by such smart devices
so that we don't end up with piles of vendor specific modules.
Now I hear you say: "No chance short term" ;)
Right, that's why I'ld like to cover such hassle in userspace rather than
in the kernel if possible.
> This is why we'll
> do a better job of error reporting in fastfail.
:)
>
> James
>
--
Regards,
Heinz -- The LVM Guy --
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
Mauelshagen@Sistina.com +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
prev parent reply other threads:[~2003-08-19 16:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20030819073926.GA423@fib011235813.fsnet.co.uk>
[not found] ` <20030819094838.F8428@sistina.com>
2003-08-19 9:04 ` [lvm] [christophe.varoqui@free.fr: dm multipath target] christophe.varoqui
2003-08-19 9:51 ` Heinz J . Mauelshagen
2003-08-19 10:48 ` christophe.varoqui
2003-08-19 12:35 ` Heinz J . Mauelshagen
2003-08-19 13:14 ` christophe.varoqui
2003-08-19 13:26 ` christophe.varoqui
2003-08-19 16:23 ` Heinz J . Mauelshagen
2003-08-19 23:22 ` christophe varoqui
2003-08-20 13:02 ` Heinz J . Mauelshagen
2003-08-20 14:19 ` christophe.varoqui
2003-08-21 12:47 ` Heinz J . Mauelshagen
2003-08-21 16:34 ` christophe.varoqui
2003-08-22 8:51 ` Heinz J . Mauelshagen
2003-08-22 14:59 ` Patrick Mansfield
2003-08-22 15:34 ` christophe.varoqui
2003-08-22 15:55 ` Patrick Mansfield
2003-08-22 16:07 ` christophe.varoqui
2003-08-19 14:19 ` James Bottomley
2003-08-19 16:09 ` Heinz J . Mauelshagen [this message]
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=20030819180948.N8420@sistina.com \
--to=heinz.mauelshagen@t-online.de \
--cc=James.Bottomley@steeleye.com \
--cc=christophe.varoqui@free.fr \
--cc=linux-scsi@vger.kernel.org \
--cc=mauelshagen@sistina.com \
--cc=mge@sistina.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox