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.