Subject: Re: Recent buffer cache fixes; softdep win(?)
To: Daniel Carosone <dan@geek.com.au>
From: Markus W Kilbinger <kilbi@rad.rwth-aachen.de>
List: port-sparc
Date: 02/01/2004 19:49:56
>>>>> "Daniel" == Daniel Carosone <dan@geek.com.au> writes:
Daniel> On Sat, Jan 31, 2004 at 12:21:17PM +0100, Markus W Kilbinger wrote:
>> ... seem to make my sparc ipx the first time run stable with
>> softdep enabled!
>>
>> Before it ran into some kind of deadlock with more and more
>> decreasing responsiveness under heavy (disk) load...
Daniel> That's very interesting, and encouraging though for the
Daniel> wrong reasons.
Daniel> Was this a problem you had since a long time ago, or only
Daniel> in the past few weeks?
A long time (years)!
http://mail-index.netbsd.org/port-sparc/2002/01/27/0000.html
was a note about it...
Daniel> Because the behaviour that this patch changed is only a
Daniel> few weeks old.
Bummer...
Daniel> If there is a deadlock in the system somewhere, it's still
Daniel> there - it's just no longer being triggered so readily.
Daniel> Such problems have been exposed by the new bufcache
Daniel> behaviour with softdep, in that we can now generate a huge
Daniel> flood of metadata IO at once - and which this patch may do
Daniel> a better job of hiding some of that.
Daniel> But if you saw this problem with softdep before a few
Daniel> weeks ago, the underlying problem is very likely still
Daniel> there.
Ok, thanks for the clarification! The patch seems to hide the problem
completely on my ipx (at the moment ;-))!
But:
- Is this a general ubc-softdep problem then, for all
platforms/hardware, but only some/few of them show it evidently?
- Is it so hard to debug (it seems to exist for years now ...)?
Daniel> Are you using something like cgd or raidframe on this ipx?
Daniel> How much RAM does it have (probably not that much, right)?
My ipx has 64 mb of ram, no cgd or raidframe involved.
Markus.