xfs
[Top] [All Lists]

Re: Major XFS problems...

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: Major XFS problems...
From: Jakob Oestergaard <jakob@xxxxxxxxxxxxx>
Date: Thu, 9 Sep 2004 14:11:00 +0200
Cc: linux-xfs@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
In-reply-to: <20040909094255.F3951028@xxxxxxxxxxxxxxxxxxxxxxxx>
Mail-followup-to: Jakob Oestergaard <jakob@xxxxxxxxxxxxx>, Nathan Scott <nathans@xxxxxxx>, linux-xfs@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
References: <20040908123524.GZ390@xxxxxxxxxxxxx> <20040909074046.A3958243@xxxxxxxxxxxxxxxxxxxxxxxx> <20040908232210.GL390@xxxxxxxxxxxxx> <20040909094255.F3951028@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.3.28i
On Thu, Sep 09, 2004 at 09:42:55AM +1000, Nathan Scott wrote:
> Hi Jakob,
> 
...
> OK, so could you add the details on how you're managing to hit it
> into that bug?... when you say "trivially" - does that mean you
> have a recipe that is guaranteed to quickly hit it?  A reproducible
> test case would be extremely useful in tracking this down.

On the two systems where I've seen this, the recipe is to set up an
SMP+NFS+XFS server, and have a number of clients mount the exported
filesystem, then perform reads and writes...

The two servers are used very differently - one is holding a small
number of source trees that are compiled/linked on a small cluster. The
other is holding a very large number of user home directories, where the
primary use is web serving (web servers running on the NFS clients).

A google for 'debug.c:106' turns out some 120 results - it seems that no
special magic is needed, other than a few boxes to set up the test
scenario.

On the 29th of februrary, akp@xxxxxxxxxxxx submitted (as comment #23 to
bug #309) a description of a test setup along with a shell script that
was used to trigger this problem.

-- 

 / jakob


<Prev in Thread] Current Thread [Next in Thread>