On Tue, Feb 12, 2013 at 11:44:56AM -0800, Zach Brown wrote: > On Tue, Feb 12, 2013 at 06:54:49PM +0000, Richard W.M. Jones wrote: > > Btrfs has been broken for me for ages. I first reported it on this > > list 5 months ago[1]. Below is a very simple reproducer that anyone > > can run. > > The very simple reproducer doesn't fail over here on bare hardware for > me. > > # dmesg | grep -c 'device label TEST' > 808 > > (keeps it spinning) > > > *NB* before you run this, adjust /dev/sda & /dev/sda1 to point to an > > unused block device! > > What block devices are you using? I ask because how it implements > caching affects this test. > > The theory, as I understand it, is that btrfs is issuing bio reads that > don't see the cached writes from mkfs. > > You'd never see this bug on loopback because it serves bio reads from > the cache that mkfs wrote to. > > I'm not seeing it on hardware because the filemap_write_and_wait() that > btrfs does in the kernel on mount is syncing the cached writes. The bio > reads then get the mkfs data from disk. > > If your block device has a cache that doesn't sync with btrfs calls > this, you'd see this problem.. but.. that'd be strange indeed. Chris' > test patch to sync from mkfs would probably help, but you'd still see > the problem if, say, you just wrote a btrfs image to the block device > and reasonably expected the kernel to find it on mount. > > So it'd be nice to know what devices you're using. Maybe some nutty > in-guest virt passthrough thing?
It's virtio-scsi in a KVM (qemu 1.3.0) guest. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
