All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: kreijack@inwind.it
Cc: linux-btrfs@vger.kernel.org, Liu Bo <bo.li.liu@oracle.com>
Subject: Re: [PATCH v2] btrfs: handle dynamically reappearing missing device
Date: Mon, 20 Nov 2017 16:19:31 +0800	[thread overview]
Message-ID: <c721f8b5-aedb-6f28-5db9-6b48ac0c1014@oracle.com> (raw)
In-Reply-To: <2e6fd096-43c6-c6c7-90ae-ac4672ac5797@libero.it>



On 11/18/2017 09:52 PM, Goffredo Baroncelli wrote:
> On 11/17/2017 01:36 PM, Anand Jain wrote:
>> If the device is not present at the time of (-o degrade) mount,
>> the mount context will create a dummy missing struct btrfs_device.
>> Later this device may reappear after the FS is mounted and
>> then device is included in the device list but it missed the
>> open_device part. So this patch handles that case by going
>> through the open_device steps which this device missed and finally
>> adds to the device alloc list.
> 
> What happens if the first devices got writes before the "last device" is joined ?
> 
> Supposing to have a raid1 pair of devices: sda, sdb
> 
> - sda is dissappeared (usb detached ?)
> - the filesystem is mounted as
> 	mount -o degraded /dev/sdb
> - some writes happens on /dev/sdb
> - the user reattach /dev/sda
> - udev run "btrfs dev scan"
> - the system joins /dev/sda to the filesystem disks pool
> 
> Because the filesystem is a raid1, btrfs may read from /dev/sdb (updated data) or /dev/sda (old data), or worse read something from the former and something from the later (metadata from sda and data from sdb ) ???

  Thanks for the test scenario, this case is fine as its read from
  the disk having highest generation number, so we pick sdb in the
  case above.

Thanks, Anand


> Am I missing something ?
> 
> BR
> G.Baroncelli
> 

  reply	other threads:[~2017-11-20  8:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-12 10:56 [PATCH] btrfs: handle dynamically reappearing missing device Anand Jain
2017-11-15  7:38 ` kbuild test robot
2017-11-15 10:18   ` Anand Jain
2017-11-16 19:08 ` Nikolay Borisov
2017-11-17  7:46   ` Anand Jain
2017-11-16 23:28 ` Liu Bo
2017-11-17 11:53   ` Anand Jain
2017-11-28 22:52     ` Liu Bo
2017-11-17 12:36 ` [PATCH v2] " Anand Jain
2017-11-18 13:52   ` Goffredo Baroncelli
2017-11-20  8:19     ` Anand Jain [this message]
2017-11-20 19:28       ` Goffredo Baroncelli
2017-11-20 21:14         ` Anand Jain
2017-12-04  7:09         ` Anand Jain

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=c721f8b5-aedb-6f28-5db9-6b48ac0c1014@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=bo.li.liu@oracle.com \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.