Bug 909602
Summary: | xfs_growfs fails with error XFS_IOC_FSGROWFSDATA xfsctl failed: Cannot allocate memory | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Richard W.M. Jones <rjones> | |
Component: | kernel | Assignee: | Eric Sandeen <esandeen> | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 18 | CC: | bmr, dyasny, esandeen, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mbooth, pbonzini, rjones, virt-maint | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | kernel-3.7.9-205.fc18 | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | 909598 | |||
: | 918571 (view as bug list) | Environment: | ||
Last Closed: | 2013-03-06 13:51:40 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 909598, 918571 |
Description
Richard W.M. Jones
2013-02-09 19:01:25 UTC
I should add that this worked "very recently". I updated the kernel on this machine only yesterday, and I'm 99% certain it was working earlier this week. This bug does NOT appear on Rawhide (kernel-3.8.0-0.rc7.git0.1.fc19.x86_64). Hm. Doing the same[1] steps here, with 3.7.2-204 and xfsprogs-3.1.10-1 it seems to work fine here. [ 102.438071] XFS (dm-0): _xfs_buf_find: Block out of range: block 0x1e001, EOFS 0x14000 those numbers are in sectors, so: 0x14000 sectors -> 81920 sectors -> 10240 blocks (the original size) 0x1E001 sectors -> 122881 sectors -> 15360 blocks (within the new size (20480)) The "EOFS" number comes from: eofs = XFS_FSB_TO_BB(btp->bt_mount, btp->bt_mount->m_sb.sb_dblocks); which is looking at the superblock dblocks value. Not yet sure what to make of this yet ... seeing stale superblock values on the disk? [1] using a 1g file-backed loop device in place of /dev/sda, on a normally-booted F18 guest. Same success for a not-file-backed-loop device; using separate block device (in a guest) I also had no problems. Does seem like maybe a caching issue (you had similar(?) issues w/ btrfs I think?) (In reply to comment #4) > Same success for a not-file-backed-loop device; using separate block device > (in a guest) I also had no problems. > > Does seem like maybe a caching issue (you had similar(?) issues w/ btrfs I > think?) Right, indeed I did. I'm using virtio-scsi in a KVM guest. With Fedora 18, if you use the 'virt-rescue --scratch' command suggested in comment 0, and paste in the ><rescue> commands shown, then it will use virtio-scsi (no root required!) Interesting. I can reproduce it within virt-rescue with any of virtio-scsi, virtio-blk and IDE; and with any of cache=none (aka O_DIRECT), cache=writeback, cache=writethrough. I also can reproduce it if I start the virt-rescue VM with an NBD client, backed by either qemu-nbd or nbd-server. It works with kernel-3.7.5-201.fc18.x86_64 as the guest kernel and fails with 3.7.6-201.fc18.x86_64. I think this could be the culprit: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end http://permalink.gmane.org/gmane.linux.kernel/1433881 I failed to reproduce it outside a guest with either NBD or loop devices, then realized I haven't yet rebooted my machine after installing 3.7.6! :) I'm seeing this in F17, also with 3.7.6. $ rpm -q kernel xfsprogs kernel-3.6.11-1.fc17.x86_64 kernel-3.6.11-5.fc17.x86_64 kernel-3.7.6-102.fc17.x86_64 xfsprogs-3.1.8-1.fc17.x86_64 [159508.237713] XFS (dm-3): _xfs_buf_find: Block out of range: block 0x4600001, EOFS 0x3c00000 Will test with a 3.7.5 kernel. It is fixed in 3.7.9. ><rescue> pvcreate /dev/sda Physical volume "/dev/sda" successfully created ><rescue> vgcreate VG /dev/sda Volume group "VG" successfully created ><rescue> lvcreate -L 40M -n LV /dev/VG [ 36.402854] bio: create slab <bio-1> at 1 Logical volume "LV" created ><rescue> mkfs -t xfs /dev/VG/LV meta-data=/dev/VG/LV isize=256 agcount=2, agsize=5120 blks = sectsz=512 attr=2, projid32bit=0 data = bsize=4096 blocks=10240, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=1200, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 ><rescue> lvresize -L 80M /dev/VG/LV Extending logical volume LV to 80.00 MiB Logical volume LV successfully resized ><rescue> mount /dev/VG/LV /sysroot [ 42.900172] SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled [ 42.932262] XFS (dm-0): Mounting Filesystem [ 43.011893] XFS (dm-0): Ending clean mount ><rescue> xfs_growfs -d /sysroot meta-data=/dev/mapper/VG-LV isize=256 agcount=2, agsize=5120 blks = sectsz=512 attr=2 data = bsize=4096 blocks=10240, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=1200, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 10240 to 20480 Yes, thanks - saw the revert on 3.7-stable. Works for me with both older and patched kernels. F18 seems to have moved on to 3.8.1, and I can confirm that it is fixed in this kernel. 3.7.9 is out now with the revert - filed bug 918571 for F17. |