[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