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? - z -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
