Re: [PATCH] xfsqa: new fsr defragmentation test

[Dave Chinner <david@fromorbit.com>]

On Tue, Apr 06, 2010 at 10:29:31AM -0500, Eric Sandeen wrote:
> On 04/06/2010 03:52 AM, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > 
> > This test aims to recreate the conditions that caused xfs_fsr to
> > corrupt inode forks. The problem was that the data forks between the
> > two inodes were in different formats due to different inode fork
> > offsets, so when they swapped the data forks the formats were
> > invalid.
> > 
> > This test generates a filesystem with a known fragmented freespace pattern and
> > then abuses known "behaviours" of the allocator to generate files
> > with a known number of extents. It creates attributes to generate a
> > known inode fork offset, then uses a debug feature of xfs_fsr to
> > attempt to defrag the inode to a known number of extents.
> > 
> > By using these features, we can pretty much cover the entire matrix of inode
> > fork configurations, hence reproducing the conditions that lead to corruptions.
> > This test has already uncovered one bug in the current kernel code, and the
> > current fsr (with it's naive attribute fork handling) is aborted on a couple of
> > hundred of the files created by this test.
> > 
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> > ---
> >  226     |  192 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  226.out |    2 +
> >  group   |    3 +-
> >  3 files changed, 196 insertions(+), 1 deletions(-)
> >  create mode 100644 226
> >  create mode 100644 226.out
> > 
> > diff --git a/226 b/226
> > new file mode 100644
> > index 0000000..b92292a
> > --- /dev/null
> > +++ b/226
> > @@ -0,0 +1,192 @@
> > +#! /bin/bash
> > +# FS QA Test No. 222
> 
> s/b 226

Ah, yeah, will fix.

> Looks like a good test but how fragile will it be in the face of changes
> to the known allocator behaviors?  :)

It should be OK because the freespace is pretty robustly fragmented.
The allocator will always give fragemented files regardless of the
write patterns - it's just a question of how big the fragments will
be.

The only allocator behaviour being relied on is that it tries to
make the reverse sequential write block adjacent to the previous
block, but it can't find one because the previous block is always
carved from the first block of the free extent chosen by the
allocator. It'll take a pretty major shakeup of the allocator to
change that behaviour, and if we change it that much, tests all over
the place break....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs