On Thursday 26 of April 2012 20:54:47 Duncan wrote: > Helmut Hullen posted on Thu, 26 Apr 2012 13:11:00 +0200 as excerpted: > > Hallo, Bart, > >> > >> Well I think there is a btrfs superblock still present from the > >> full-disk filesystem. Due to the offset of the first partition from the > >> start of the disk, this superblock was not overwritten when you created > >> the filesystem inside the partition. > > > > Sounds familiar ... > > > > I now use to delete about the first 10 MByte of the target disk via "dd > > if=/dev/zero" > > But /unlike/ reiserfs, which was only affected with the well warned as > don't-use-unless-you-have-to fsck --rebuild-tree option, it seems that > due to btrfs scan, etc, btrfs has its similar problem in more routine > operation.
I'd say that this kind of problem is basically impossible in btrfs because of FS UUID written all over the tree. What we see here, is a superblock that is written in *very* specific place on the partition, that just is aligned in place that makes the whole disk look like btrfs. I don't think it's actually possible for btrfs to put a file with btrfs filesystem image in place where it could seem like the basic block device has btrfs /too/. It depends on whatever the metadata block is allocated before data block on disk. It /may/ be possible in mixed data-metadata allocation mode. Chris or Josef, can you confirm? Still, a "zero-superblock" option would be useful for the btrfs tool. I'll see what I can do about this. Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl -- 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
