I've filed this bug under util-linux, because I think wipefs isn't deleting all btrfs metadata it could. But ultimately it appears to be a btrfs bug because nothing else sees the stale volume.
https://bugzilla.redhat.com/show_bug.cgi?id=889888#c15 btrfs-progs-0.20.rc1.20121017git92d9eec-1.fc18.x86_64 e2fs-progs-1.42.5-1.fc18.x86_64 kernel 3.7.1-2 Brand new 80GB virtual disk, so it's completely zero'd. 1. fdisk to create one partition, all defaults. 2. Format that sda1 with mkfs.btrfs -L first. 3. btrfs fi show displays "first" labeled volume. 4. wipefs -a /dev/sda1 and it finds btrfs metadata, ostensibly removes it. 5. btrfs fi show does NOT show "first" anymore. 6. fdisk /dev/sda again, delete the one partition; create a new partition 500MB and a second one for remaining space. 7. btrfs fi show still does not show "first". 8. mkfs.ext4 /dev/sda1 9. btrfs fi show NOW SHOWS "first" on sda1! 10. Reboot 11. btrfs fi show still shows "first" on sda1, size 80GB. Tentative conclusions: A. wipefs isn't deleting all btrfs metadata it could. B. mkfs.ext4 is refreshing stale btrfs metadata in a way that causes btrfs fi show to see. C. btrfs fi show seems to blatantly disregard the partition map, because it shows a volume the partition map cannot possibly validly support. D. Nothing else sees this phantom btrfs volume. btrfs fi show seems confused. Chris Murphy-- 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
