[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] 2.6.2-udm2

On Sat, Feb 21, 2004 at 12:40:10AM +0100, Lars Marowsky-Bree wrote:
> On 2004-02-20T17:40:42,
>    Heinz Mauelshagen <Mauelshagen 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 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 redhat com
> https://www.redhat.com/mailman/listinfo/dm-devel


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
Mauelshagen RedHat com                            +49 2626 141200
                                                       FAX 924446

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]