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 18.104.22.168, 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 22.214.171.124 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.
Maybe this looks familiar to you and suggests that I missed
something. If so, please let me know.
ellijay:/mnt/makki/ecashin/opt-amd64/xfstests# diff -U15 078.out 078.out.bad
--- 078.out 2008-03-05 00:25:08.000000000 -0500
+++ 078.out.bad 2008-08-29 16:41:34.537888000 -0400
@@ -194,18 +194,18 @@
=== GROWFS (from 1t to 16000g, 4096 blocksize)
*** mkfs loop file (size=1t)
meta-data=DDEV isize=XXX agcount=N, agsize=XXX blks
data = bsize=XXX blocks=XXX, imaxpct=PCT
= sunit=XXX swidth=XXX, unwritten=X
naming =VERN bsize=XXX
log =LDEV bsize=XXX blocks=XXX
realtime =RDEV extsz=XXX blocks=XXX, rtextents=XXX
*** extend loop file
wrote 4096/4096 bytes at offset 17179869184000
*** mount loop filesystem
*** grow loop filesystem
xfs_growfs --BlockSize=4096 --Blocks=268435456
-data blocks changed from 268435456 to 4194304001
+data blocks changed from 268435456 to 4194304000
*** all done
Ed Cashin <ecashin@xxxxxxxxxx>