On Sep 2, 2014, at 12:02 AM, Duncan <1i5t5.duncan@xxxxxxx> wrote: > The only benefit to raid5/raid6 mode at > this time is that assuming it survives without a device loss until the > raid5/6 mode code is complete, you'll get a "free" upgrade to raid5/6 at > that point, since it has actually been doing the writes for it all along, > it just doesn't have the recovery code done yet. Normally mounted the fixing of corrupt blocks does happen, but the fixes aren't written back to disk. Same for scrub, the problems are noted along with the path to the affected file (if you don't see this, it probably means fs metadata has been corrupt), but the fixes aren't written back to disk. Degraded mount, btrfs replace doesn't work, you need to use device add, device delete. This appears to do a rebuild in that it can now be mounted normally. Maybe a balance is also necessary after this, I haven't tested how well it tolerates additional device failures without having done a balance after device delete (missing). > Tho at least scrub has some raid5/6 patches floating around, which I > /think/ might have made it into the I /think/ still soon to be released > btrfs-progs-3.16 Doesn't appear to be the case: Sep 02 14:21:05 twenty1.localdomain kernel: BTRFS: checksum error at logical 2186412032 on dev /dev/sde, sector 2116736, root 5, inode 258, offset 0, length 4096, links 1 (path: images/IMG_3327.tif) Sep 02 14:21:05 twenty1.localdomain kernel: BTRFS: bdev /dev/sde errs: wr 0, rd 0, flush 0, corrupt 1, gen 0 Sep 02 14:21:05 twenty1.localdomain kernel: BTRFS: unable to fixup (regular) error at logical 2186412032 on dev /dev/sde 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
