Hi all, Nathan.
Included you'll find a little python script that just breaks the FS in a
matter of seconds.
We are a data shop, we eat disks for breakfast, lunch and dinner. For
some testing purposes, I created a little script for filling 2-5-10 TB
with an almost identical structure we are using for our data aquisition
backends. Bonnie and the likes end their tests where we want to start.
In there some comments that could be plain wrong, feel free to shoot at
I'm NOT an FS expert
I'm NOT a programmer
On Wed, 2004-06-02 at 10:10, Nathan Scott wrote:
> On Tue, Jun 01, 2004 at 12:21:21PM +0200, Jan De Landtsheer wrote:
> > Nathan,
> > Easy.
> > take stock kernel (up till 2.6.6) eventually apply evms patches, but no
> > need... I had it with stock kernels too
> > make oldconfig from included config.gz
> > create a raid with raidtools,mdadm,evms. put files on there as
> > needed (as I saw that it only occurs on a / mounted md device)
> > boot it
> > hammer 10 minutes (rsync is very effective) -> you'll get:
> > XFS internal error XFS_WANT_CORRUPTED_GOTO at line 866 of file
> > fs/xfs/xfs_ialloc.c. Caller 0xffffffff8023ee04
> > included : config.gz, call stack trace.
> > If you need other info, feel free to ask. I was getting desperate ;-)
> > Jan
> OK, I hit this once today. Have a bunch of notes about what
> may be happening, and have not been able to hit it again. :(
> If theres anything that makes it more likely to hit (or even
> deterministic, but thats too much to hope for ;), that would
> still help me greatly. The common theme from the two folks
> who sent me info is use of rsync, and thats what I was using
> when I hit it too.. but subsequent runs on exactly the same
> data and devices has proved unsuccessful at reproducing. I'll
> keep plugging away.
> (Christoph, following on from some of our discussions - this
> doesn't look root filesystem / remount,ro related, cos I hit
> it without either of those things. I'll send all the info I
> extracted around later).
Description: GNU Zip compressed data