Re: delete missing /dev/sdd which is now added as /dev/sdd1

[Duncan <1i5t5.duncan@cox.net>]

Rasmus Abrahamsen posted on Wed, 13 Aug 2014 17:36:06 +0200 as excerpted:

>  I now did the following
> 
> dd if=/dev/zero of=/dev/sdd
> 
> Finally, btrfs does not recognize the partition as part of my raid
> anymore, but what's worse is that it now tells me that two missing
> devices is a no go, so I cannot mount it as anything but read-only. All
> the data is there, /dev/sdd1 was never used and /dev/sdd was the
> originally missing one. Mounting as read-only prevents you from adding
> devices.

There's a patch in-flight that should, I believe, help with this.  I
haven't followed the specific details, but IIRC, it has something to do
with a missing sysfs entry.  Because of that missing entry, btrfs
(userspace) doesn't have the same view of filesystem device status that
the kernel has, and device add/replace/delete can go haywire.
Additionally, in some cases it triggers too many missing devices errors,
forcing the mount read-only, which in turn won't let you add devices to
fix the problem even if due to the circumstances you know all files are
actually there and intact.

So at this point you have three choices:

1) Give up on the filesystem, do a mkfs and go from there.

2) Wait for the patch to make it into kernel 3.17 and go from there.

3) Go read the list and find and cherrypick that patch, then rebuild with
it included, and go from there.


Meanwhile, an observation on the btrfs behavior that contributed to
getting you into this situation in the first place, and how to avoid it in
the future:

Btrfs filesystem and filesystem device detection relies on a "magic
string" found in the superblock to identify btrfs filesystems, and other
metadata within the superblock to determine what specific btrfs filesystem
it belongs to.  When events such as btrfs device add/delete/ replace that
change the devices composing a filesystem don't complete properly, this
superblock information can remain to confuse btrfs when it tries working
with the remaining device components in the filesystem.

That's what was happening to you, tho the missing sysfs entries mentioned
above make the situation rather worse.  Btrfs was still detecting these
remaining bits of superblock information saying that the device in
question belonged to the btrfs it originated with, and was getting
confused.

One way to avoid this problem is to use a tool called wipefs, part of
util-linux, to erase the magic-string btrfs detection uses, so that
particular device will no longer be detected as part of a btrfs, and thus
can't confuse btrfs.  Alternatively, you can simply zero-out the correct 8
bytes on the raw device manually, using for instance dd to write directly
to the device.

See this link from the btrfs wiki problem-FAQ for more (including how to
restore the 8-byte magic string using dd if you decide you made a mistake,
something not really possible if you zero out the entire device as you did
above):

https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#How_to_clean_up_old_superblock_.3F

-- 
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