Marc MERLIN posted on Sun, 23 Mar 2014 11:58:16 -0700 as excerpted: > On Sun, Mar 23, 2014 at 11:09:07AM -0700, Marc MERLIN wrote: >> I found out that a drive that used to be part of a raid system that is >> mounted and running without it, btrfs apparently decides that the drive >> is part of the mounted raidset and in use. >> As a result, I had to eventually dd 0's over it, btrfs device scan, and >> finally I was able to use it again. > > I filed a bug for this, it's a bit more minor, but worth fixing > eventually https://bugzilla.kernel.org/show_bug.cgi?id=72771 The reason for this is the device-scanning that btrfs does, detecting btrfs superblocks in ordered to assemble filesystems from multiple devices, etc. The canonical method for wiping such superblocks and thus avoiding btrfs detecting it as a btrfs filesystem component is to use wipefs, part of the util-linux package. I think it's covered somewhere on the wiki; let me see if I can find it... Yes. See the problem-FAQ: https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#How_to_clean_up_old_superblock_.3F As you'll note, however, it mentions the dd method as a workaround if wipefs isn't available, but all you need to wipe is the 8-byte magic string. =:^) (Tho there's three superblocks and while wiping the first is generally enough and is all wipefs does, you can wipe the others too if you like as well. There are also instructions for restoring the magic string using dd, if it should be come necessary.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
