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