Stefan Behrens <sbehrens <at> giantdisaster.de> writes:
> TM, Just read the man-page. You could have used the replace tool after > physically removing the failing device. > > Quoting the man page: > "If the source device is not available anymore, or if the -r option is > set, the data is built only using the RAID redundancy mechanisms. > > Options > -r only read from <srcdev> if no other zero-defect mirror > exists (enable this if your drive has lots of read errors, > the access would be very slow)" > > Concerning the rebuild performance, the access to the disk is linear for > both reading and writing, I measured above 75 MByte/s at that time with > regular 7200 RPM disks, which would be less than 10 hours to replace a > 3TB disk (in worst case, if it is completely filled up). > Unused/unallocated areas are skipped and additionally improve the > rebuild speed. > > For missing disks, unfortunately the command invocation is not using the > term "missing" but the numerical device-id instead of the device name. > "missing" _is_ implemented in the kernel part of the replace code, but > was simply forgotten in the user mode part, at least it was forgotten in > the man page. > Hi Stefan, thank you very much, for the comprehensive info, I will opt to use replace next time. Breaking news :-) from Jul 19 14:41:36 microserver kernel: [ 1134.244007] btrfs: relocating block group 8974430633984 flags 68 to Jul 22 16:54:54 microserver kernel: [268419.463433] btrfs: relocating block group 2991474081792 flags 65 Rebuild ended before counting down to 00000000 So flight time was 3 days, and I see no more messages or btrfs processes utilizing cpu. So rebuild seams ready. Just a few hours ago another disk showed some earlly touble accumulating Current_Pending_Sector but no Reallocated_Sector_Ct yet. TM -- 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
