On 2004-02-18T13:01:29,
Heinz Mauelshagen <mauelshagen@xxxxxxxxxx> said:
> > - The test interval is no longer passed in with the target
> > parameters (tools writers take note.
> >
> > - The kernel now does no path testing at all, let userland do it
> > (see thread on lkml).
>
> I'm not convinced that we can recover from OOM situations with either
> approach (userpace testing or dm testing of failed paths).
I'm thinking that if you have run yourself into such a failure - ie all
paths currently down, swap on the failed m-p device, OOM _and_ needing
to allocate memory / swapping - the system is in a very very sick state
anyway. Handling it perfectly may just not be possible.
> But if *all* paths of the multipath target to test are failed *and*
> the system is OOM, the driver accessed to queue the test io can sleep
> on allocating memory (either calling [kv]malloc() directly or
> indirectly through mempools).
>
> That memory allocation is in danger to deadlock, because pageouts are
> needed involving the very multipathed target we want to unfail.
>
> The 'workaround' for this which is reloading the table in order to set
> all paths to operational again would involve memory allocation as well
> :(
Yes. I actually see no way around this, except to tap into a general
'emergency' memory pool. I thought there was something like it, but I
forgot the name ;-) Doesn't pvmove use the same?
Sincerely,
Lars Marowsky-Brée <lmb@xxxxxxx>
--
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ -- Samuel Beckett
