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.