On Sun, Dec 17, 2017 at 8:48 AM, Peter Grandi <p...@btrfs.list.sabi.co.uk> wrote: > "Duncan"'s reply is slightly optimistic in parts, so some > further information...
>> and it should detect a device coming back as a different >> device too. > > That is disagreeable because of poor terminology: I guess that > what was intended that it should be able to detect a previous > member block-device becoming available again as a different > device inode, which currently is very dangerous in some vital > situations. Duncan probably means if the device reappears with different enumeration (was /dev/sdb1 but comes back as /dev/sde1), that Btrfs can recover from this by using the Btrfs specific dev.uuid to recognize the device. And also by knowing generation it in effect has a virtual write intent bitmap to use to catch up that device for missing commits, which is something that doesn't currently happen automatically; it requires either a scrub or balance to catch up a formerly missing device - a very big penalty because the whole array has to be done to catch it up for what might be only a few minutes of missing time. -- Chris Murphy -- 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
