From: Goffredo Baroncelli <kreijack@gmail.com>
To: "Michael Kjörling" <michael@kjorling.se>
Cc: linux-btrfs@vger.kernel.org, Hugo Mills <hugo@carfax.org.uk>,
Chris Murphy <lists@colorremedies.com>
Subject: Re: device delete, error removing device
Date: Tue, 23 Oct 2012 20:10:54 +0200 [thread overview]
Message-ID: <5086DDAE.3050708@gmail.com> (raw)
In-Reply-To: <20121023075721.GB391@yeono.kjorling.se>
On 2012-10-23 09:57, Michael Kjörling wrote:
> On 22 Oct 2012 18:18 +0100, from hugo@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.
IIRC Chris [Mason] told that when a disk is removed, the super-block
(signature) is zeroed and a sync is issued. Looking at the code,
confirm it:
form fs/btrfs/volume.c:
int btrfs_rm_device(struct btrfs_root *root, char *device_path)
{
[...]
/*
* at this point, the device is zero sized. We want to
* remove it from the devices list and zero out the old super
*/
if (clear_super) {
/* make sure this device isn't detected as part of
* the FS anymore
*/
memset(&disk_super->magic, 0, sizeof(disk_super->magic));
set_buffer_dirty(bh);
sync_dirty_buffer(bh);
}
[...]
I think that what Chris [Murphy] was reported is a bug of the btrfs
user space program (which is corrected in the latest git).
Unfortunately we don't know which version Chris is using so we cannot
reach a conclusion (if the bug was corrected, or it is a new bug).
BR
G.Baroncelli
>
> 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.
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2012-10-23 18:10 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 4:32 device delete, error removing device Chris Murphy
2012-10-22 5:04 ` dima
2012-10-22 5:30 ` Chris Murphy
2012-10-22 6:02 ` Chris Murphy
2012-10-22 9:19 ` Hugo Mills
2012-10-22 16:42 ` Chris Murphy
2012-10-22 17:04 ` Goffredo Baroncelli
2012-10-22 19:36 ` Chris Murphy
2012-10-22 19:50 ` Hugo Mills
2012-10-22 20:35 ` Goffredo Baroncelli
2012-10-22 20:46 ` Chris Murphy
2012-10-22 17:18 ` Hugo Mills
2012-10-23 7:57 ` Michael Kjörling
2012-10-23 18:10 ` Goffredo Baroncelli [this message]
2012-10-23 18:17 ` Chris Murphy
2012-10-23 19:02 ` Goffredo Baroncelli
2012-10-23 20:28 ` Chris Murphy
2012-10-23 22:16 ` Goffredo Baroncelli
2012-10-23 22:29 ` Chris Murphy
2012-10-24 18:06 ` device delete, error removing device [SOLVED] Goffredo Baroncelli
2012-10-24 19:13 ` Chris Murphy
2012-10-24 21:30 ` Goffredo Baroncelli
2012-10-24 21:43 ` Chris Murphy
2012-10-25 19:26 ` Goffredo Baroncelli
2012-10-27 18:25 ` device delete, error removing device Chris Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5086DDAE.3050708@gmail.com \
--to=kreijack@gmail.com \
--cc=hugo@carfax.org.uk \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=michael@kjorling.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).