xfs
[Top] [All Lists]

Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD)

To: linux-kernel@xxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
Subject: Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD)
From: Gregory Brauer <greg@xxxxxxxxxxxxx>
Date: Wed, 18 May 2005 13:53:22 -0700
Cc: Jakob Oestergaard <jakob@xxxxxxxxxxxxx>, Joshua Baker-LePain <jlb17@xxxxxxxx>, Chris Wedgwood <cw@xxxxxxxx>
In-reply-to: <20050518202014.GZ422@xxxxxxxxxxxxx>
References: <428511F8.6020303@xxxxxxxxxxxxx> <20050514184711.GA27565@xxxxxxxxxxxxxxxxxxxxx> <428B7D7F.9000107@xxxxxxxxxxxxx> <20050518175925.GA22738@xxxxxxxxxxxxxxxxxxxxx> <20050518195251.GY422@xxxxxxxxxxxxx> <Pine.LNX.4.58.0505181556410.6834@xxxxxxxxxxxxxxxxxx> <20050518202014.GZ422@xxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
Jakob Oestergaard wrote:
> You want a few million files on the FS in order to confuse the server
> sufficiently for it to screw up severely.

Here we reproduced the OOPS with an fresh and empty XFS volume using
the nfs_fsstress.sh script.

> And don't run as root - common problems are also that files get wrong
> ownership/modes (a file created by one unprivileged user shows up as
> belonging to another unprivileged user - files can show up with modes
> d---------)

Our nfs_fsstress.sh tests were running as root and writing only
root-owned files (with no_root_squash, of course) and reproduced
the OOPS twice.  We haven't seen the privileges problem yet.

Greg


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