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 ? In this case, would be better an explicit user intervention instead of an automatic one ? > > Thanks, Anand > > >> Am I missing something ? >> >> BR >> G.Baroncelli >> > -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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
