xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Invalid argument

Hi list,

I'm getting the error "xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed:
Invalid argument" while trying to grow an XFS partition.

This is on openSUSE 11.1 64 bit, with xfsprogs-2.10.2-3.1 from
http://download.opensuse.org/repositories/filesystems/openSUSE_11.1/x86_64/xfsprogs-2.10.2-3.1.x86_64.rpm

This error is the same or looks similar to the one reported some months ago at http://oss.sgi.com/archives/xfs/2009-02/msg00028.html .

There is apparently a fix for it, see
http://oss.sgi.com/archives/xfs/2008-12/msg01794.html :

*********************************************************
commit 471d59103167c84f17b9bcfee22ed10b44ff206e

Author: sandeen@xxxxxxxxxxx <sandeen@xxxxxxxxxxx>
Date:   Tue Nov 25 21:20:10 2008 -0600

[XFS] Add compat handlers for data & rt growfs ioctls

The args for XFS_IOC_FSGROWFSDATA and XFS_IOC_FSGROWFSRTA have padding on the end on intel, so add arg copyin functions, and then just call the growfs ioctl helpers.

Signed-off-by Eric Sandeen <sandeen@xxxxxxxxxxx>

Reviewed-by Christoph Hellwig <hch@xxxxxx>

Signed-off-by Lachlan McIlroy <lachlan@xxxxxxx>

*********************************************************

I tried different 2.6.27 versions, one 2.6.29 and one 2.6.30-rc6 version, all gave the same error, check
https://bugzilla.novell.com/show_bug.cgi?id=506361 for the different kernel versions and errors.

Is this fix still not included in Linus / openSUSE trees?

Or am I hitting another error?

Thanks, Richard

Quoted 5 lines · Richard Ems

Hi list,

I'm getting the error "xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed:
Invalid argument" while trying to grow an XFS partition.

Quoted 2 lines

This is on openSUSE 11.1 64 bit, with xfsprogs-2.10.2-3.1 from
http://download.opensuse.org/repositories/filesystems/openSUSE_11.1/x86_64/xfsprogs-2.10.2-3.1.x86_64.rpm

The compat handlers should only matter if you're using 32 bit userspace with a 64 bit kernel...

Are you certain that your xfsprogs userspace is 64-bit?

Quoted 24 lines

This error is the same or looks similar to the one reported some months ago at http://oss.sgi.com/archives/xfs/2009-02/msg00028.html .

There is apparently a fix for it, see
http://oss.sgi.com/archives/xfs/2008-12/msg01794.html :

*********************************************************
commit 471d59103167c84f17b9bcfee22ed10b44ff206e

Author: sandeen@xxxxxxxxxxx <sandeen@xxxxxxxxxxx>
Date:   Tue Nov 25 21:20:10 2008 -0600

[XFS] Add compat handlers for data & rt growfs ioctls

The args for XFS_IOC_FSGROWFSDATA and XFS_IOC_FSGROWFSRTA have padding on the end on intel, so add arg copyin functions, and then just call the growfs ioctl helpers.

Signed-off-by Eric Sandeen <sandeen@xxxxxxxxxxx>

Reviewed-by Christoph Hellwig <hch@xxxxxx>

Signed-off-by Lachlan McIlroy <lachlan@xxxxxxx>

*********************************************************

Quoted 4 lines

I tried different 2.6.27 versions, one 2.6.29 and one 2.6.30-rc6 version, all gave the same error, check
https://bugzilla.novell.com/show_bug.cgi?id=506361 for the different kernel versions and errors.

I don't see in that bug where you tested .29 or .30, or what the results were...

Quoted 3 lines

Is this fix still not included in Linus / openSUSE trees?

As for Linus' tree, AFAIK everything works; I can't speak to what SuSE has.

Quoting Eric Sandeen <[email protected]>:

Quoted 1 line

Richard Ems wrote:

Quoted 6 lines

Quoted 4 lines

I tried different 2.6.27 versions, one 2.6.29 and one 2.6.30-rc6 version, all gave the same error, check
https://bugzilla.novell.com/show_bug.cgi?id=506361 for the different kernel versions and errors.

I don't see in that bug where you tested .29 or .30, or what the results were...

Sorry, I wrote a 2nd comment into bugzilla but forgot to submit it 8( . Now it's there, please check again (
https://bugzilla.novell.com/show_bug.cgi?id=506361#c1 ) .

Quoted 1 line

Quoted 2 lines

Quoted 1 line

Is this fix still not included in Linus / openSUSE trees?

As for Linus' tree, AFAIK everything works; I can't speak to what SuSE has.

So the Vanilla kernel I tried should have this fix included, is it then a new bug?

Not sure ... how big is the current fs and how big is the device? Can you provide:

# xfs_info /mnt
# grep sda1 /proc/partitions

Quoting Eric Sandeen <[email protected]>:

Quoted 5 lines

Not sure ... how big is the current fs and how big is the device? Can you provide:

# xfs_info /mnt
# grep sda1 /proc/partitions

It is a 16TB FS, and I add 4 x 1 TB HDDs to the RAID 6 array, so the device went from 16 TB to 20 TB.

c3m:~ # xfs_info /backup/IFT
meta-data=/dev/sda1 isize=256 agcount=52, agsize=76288719 blks
= sectsz=512 attr=1
data = bsize=4096 blocks=3905982455, imaxpct=25
= sunit=0 swidth=0 blks

naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=32768, version=1

= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0

c3m:~ # grep sda1 /proc/partitions

    8     1 19529912286 sda1

Quoted 20 lines · [email protected] wrote:

Quoting Eric Sandeen <[email protected]>:

Quoted 5 lines

Not sure ... how big is the current fs and how big is the device? Can you provide:

# xfs_info /mnt
# grep sda1 /proc/partitions

It is a 16TB FS, and I add 4 x 1 TB HDDs to the RAID 6 array, so the device went from 16 TB to 20 TB.

c3m:~ # xfs_info /backup/IFT
meta-data=/dev/sda1 isize=256 agcount=52, agsize=76288719 blks
= sectsz=512 attr=1
data = bsize=4096 blocks=3905982455, imaxpct=25
= sunit=0 swidth=0 blks

naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=32768, version=1

= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0

Quoted 2 lines

c3m:~ # grep sda1 /proc/partitions

    8     1 19529912286 sda1

thanks, with that info I can reproduce it, I'll look into it soon... but not today.

if you growfs to a nr of blocks that is about 55 blocks less than the actual device size, it should succeed for you. There's a case where the last AG would be too small and it tries to compensate but there's an overflow, I'll send a patch.

if you growfs to a nr of blocks that is about 55 blocks less than the actual device size, it should succeed for you. There's a case where the last AG would be too small and it tries to compensate but there's an overflow, I'll send a patch.