This was found by the libguestfs test suite (RHBZ#909598). Description of problem: $ virt-rescue --scratch [...] ><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 [ 46.452610] 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 [ 74.621050] SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled [ 74.645368] XFS (dm-0): Mounting Filesystem [ 74.812144] 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 [ 102.438071] XFS (dm-0): _xfs_buf_find: Block out of range: block 0x1e001, EOFS 0x14000 [ 102.439586] XFS (dm-0): _xfs_buf_find: Block out of range: block 0x1e001, EOFS 0x14000 xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Cannot allocate memory Version-Release number of selected component (if applicable): libguestfs from git (approximately 1.21.8) kernel-3.7.6-201.fc18.x86_64 qemu-kvm-1.2.2-4.fc18.x86_64 xfsprogs-3.1.10-1.fc18.x86_64 (These are all the latest versions in Fedora 18 at time of writing. I did not try Rawhide yet) How reproducible: 100% Steps to Reproduce: See above.
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.