On 11/21/2017 03:28 AM, Goffredo Baroncelli wrote:
On 11/20/2017 09:19 AM, Anand Jain wrote:
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.
Ok, so in this case which is the benefit to add a disk ?
With a lover number generation, the added will be used at all ?
It will be used for new writes, it will stripe across both the disks.
Balance is only for the older single chunks, which in the long term
would go away when we are able to create a degraded raid1 chunks.
In this case, would be better an explicit user intervention instead of an
automatic one ?
Without this patch the disk already joins the raid group.
But it had a bug that it missed joining the alloc group.
Thanks, Anand
Thanks, Anand
Am I missing something ?
BR
G.Baroncelli
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
