On 22 Oct 2012 18:18 +0100, from hugo@carfax.org.uk (Hugo Mills):

quoted

[root@f18v ~]# btrfs device delete /dev/sdb /mnt
[root@f18v ~]# btrfs fi show
failed to read /dev/sr0
Label: none  uuid: 6e96a96e-3357-4f23-b064-0f0713366d45
	Total devices 5 FS bytes used 7.52GB
	devid    5 size 12.00GB used 4.17GB path /dev/sdf
	devid    4 size 12.00GB used 4.62GB path /dev/sde
	devid    3 size 3.00GB used 2.68GB path /dev/sdd
	devid    2 size 3.00GB used 2.68GB path /dev/sdc
	*** Some devices missing

However, I think that last line is a bug. When I

[root@f18v ~]# btrfs device delete missing /mnt

I get

[ 2152.257163] btrfs: no missing devices found to remove

So they're missing but not missing?

   If you run sync, or wait for 30 seconds, you'll find that fi show
shows the correct information again -- btrfs fi show reads the
superblocks directly, and if you run it immediately after the dev del,
they've not been flushed back to disk yet.

That sounds like it has the potential to bite a lot of people in the
rear. Yes, 30 seconds or a sync is trivial, but only if you know about
it.

Considering that a device delete is a pretty rare but potentially
important operation, would it not be better for a sync to be done
automatically after a "device delete" command? And potentially others
in a similar vein. With an option --no-sync or similar to disable the
behavior (in the relatively unlikely situation that multiple devices
are unavailable and need to be deleted, for example).

I can definitely see the described behavior qualifying as a "WTF?"
moment.

-- 
Michael Kjörling • http://michael.kjorling.se • michael@kjorling.se
                “People who think they know everything really annoy
                those of us who know we don’t.” (Bjarne Stroustrup)