[dm-devel] 2.6.2-udm2

Heinz Mauelshagen Mauelshagen at redhat.com
Mon Feb 23 05:43:14 UTC 2004


On Sat, Feb 21, 2004 at 12:40:10AM +0100, Lars Marowsky-Bree wrote:
> On 2004-02-20T17:40:42,
>    Heinz Mauelshagen <Mauelshagen at redhat.com> said:
> 
> > > > in a fabric, which come back online shortly later when all paths have been
> > > > failed by the multipath target.
> > > You think EIO is the wrong response to this ?
> > In case all paths come back after a reasonably short time it is.
> 
> Can you define 'reasonably short time'?

Defined by the amount it takes for a full system reboot
and application startup, which can take multiple minutes.

IOW: defined by the user.

> 
> If they come back faster than a single SCSI timeout: we are covered.

Of course.

> 
> Otherwise, I'd say we should place the limit at 'We can only queue so
> much until we run out of memory'; alas, the failure case which you bring
> up is swapping to a fully disconnected m-p device under OOM, and that's
> pathological.

Is it ?

If user has a bullet prove multipath solution in operation, which needs to
be able to reuse a repaired path after the system went OOM, he'll surely
prefer this vs. a longish system reboot with client recovery (thise might
be thousands) including lots of helpdesk inquiries.

We should give user the freedom of choice, if he prefers to take a system
starvation for a definable amount of time -or- wants to fail the
filesystem/application directly after all paths went south.

I had system environments where a full system reboot took ~15 minutes.
In such cases you'll surely would appreciate to have the option to repair
a path (eg, replacing the dead FC cable) in order to recover sooner.

>
> 
> Sincerely,
>     Lars Marowsky-Brée <lmb at suse.de>
> 
> -- 
> High Availability & Clustering	      \ ever tried. ever failed. no matter.
> SUSE Labs			      | try again. fail again. fail better.
> Research & Development, SUSE LINUX AG \ 	-- Samuel Beckett
> 
> --
> dm-devel mailing list
> dm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Red Hat GmbH
Consulting Development Engineer                   Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen at RedHat.com                            +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-




More information about the dm-devel mailing list