linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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