On 22 Oct 2012 18:18 +0100, from h...@carfax.org.uk (Hugo Mills): >> [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 • mich...@kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup)
signature.asc
Description: Digital signature
