Re: xfs_growfs fix backport for 2.6.16.y

[Dave Chinner <david@fromorbit.com>]

On Wed, Sep 03, 2008 at 02:27:02PM -0400, Ed Cashin wrote:
> On Tue, Aug 26, 2008 at 12:01:01PM +1000, Dave Chinner wrote:
> > On Mon, Aug 25, 2008 at 11:39:31AM -0400, Ed Cashin wrote:
> ...
> > > I backported your fix,
> > > 
> > >     commit 20f4ebf2bf2f57c1a9abb3655391336cc90314b3
> ...
> > > ... to the 2.6.16.y git tree, and the result is included below.  When
> > > I apply this backported fix to 2.6.16.62, I can grow an online XFS by
> > > 10 terabytes without any trouble.
> 
> ...
> > I suggest you make sure it passes test 078 in the xfsqa suite (part
> > of the xfs-cmds tree) as that tests all the nasty growfs corner
> > cases. You'll need to test it on 32 bit and 64 bit machines....
> > 
> > If it passes that then I don't see any problems - SGI backported
> > this for sles10 which is based on 2.6.16 a long time ago.
> 
> On a 64-bit system running 2.6.16.62 with this patch, test 078 does
> not succeed because of one difference in the output file, the line in
> the diff below.  Instead of a new size of 4194304001 blocks, the new
> size is 4194304000 blocks.

Ah, yes. That. I think Barry can try to explain that one because:

http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/078.out.diff?r1=1.3;r2=1.4

The test golden output was changed instead of someone understanding
why the fixes to growfs changed the size that the filesystem was
grown to. ISTR being opposed to changing the golden output because
it was the wrong thing to do and would break QA on older kernels,
not to mention that it indicated some possible off-by-one bug in
a change that had been made at some point...

Other than that, the backport should be fine given it passed all the
other parts of the test....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com