On 2004-02-18T09:38:38, Patrick Mansfield <patmans@xxxxxxxxxx> said: > Yes, but memory starvation (that will be recovered from) is better than an > oops, and in some cases better than application downtime. Iff it will be recovered from later (and quickly enough before we die completely anyway). In such scenarios, quick failover to another node may be the best option, and that means reporting the error upwards ASAP, and not delaying it for the length of some arbitary timeout. It's a policy decision though, but I'd repeat my point that the policy of blocking isn't the best answer. And that can be divided into two aspects, even: - Queuing IO while all paths are down may be a route for some systems. If you have the memory to queue, that is, and don't want quick failover. This should be doable. - Queuing IO in OOM situations and having the swap on the affected m-p device, now that is causing more pain than it will solve. I recall that there was some storage system which actively caused such broken scenarios because of it's 'rolling upgrade' semantics. But, I think that's a problem they ought to fix in firmware and not in the OS ;-) 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