On Feb 14, 2013, at 7:44 AM, Martin Steigerwald <Martin@xxxxxxxxxxxx> wrote: > For some reason BTRFS is still trying to write to /dev/sdd, which isn´t > there anymore. That perfectly explains those lost page writes for me. If > that is the case, this seems to me like a serious bug in BTRFS. Following the ICRC ABRT error, /dev/sdd becomes /dev/sdi. Btrfs-progs recognizes this by only listing /dev/sdi and /dev/sde as devices in the volume. But the btrfs kernel space code continues to try to write to /dev/sdd, while /dev/sdi isn't getting any writes (at least, it's not filling up with data). Btrfs kernel space code is apparently unaware that /dev/sdd is gone. That seems to be the primary problem. A question is, if the kernel space code was aware of a member device vanishing and then reappearing, whether as the same or different block device designation, should it automatically re-add the device to the volume? Upon being re-added, it would be out of sync, leading to a follow-up question about whether it should be auto-scrubbed to fix this? And yet another follow-up question which is if the file system metadata contains information that can be used similar to the function of the md write-intent bitmap, reducing the time to catch the drive up, avoiding a full scrub? Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
