On Fri, 4 Nov 2016 01:01:13 -0700 Marc MERLIN <m...@merlins.org> wrote:
> Basically I have this: > sde 8:64 0 3.7T 0 > └─sde1 8:65 0 3.7T 0 > └─md5 9:5 0 14.6T 0 > └─bcache0 252:0 0 14.6T 0 > └─crypt_bcache0 (dm-0) 253:0 0 14.6T 0 > > I'll try dd'ing the md5 directly now, but that's going to take another 2 days > :( > > That said, given that almost half the device is not readable from user space > for some reason, that would explain why btrfs check is failing. Obviously it > can't do its job if it can't read blocks. I don't see anything to support the notion that "half is unreadable", maybe just a 512-byte sector is unreadable -- but that would be enough to make regular dd bail out -- which is why you should be using dd_rescue for this, not regular dd. Assuming you just want to copy over as much data as possible, and not simply test if dd fails or not (but in any case dd_rescue at least would not fail instantly and would tell you precise count of how much is unreadable). There is "GNU ddrescue" and "dd_rescue", I liked the first one better, but they both work on a similar principle. Also didn't you recently have issues with bad block lists on mdadm. This mysterious "unreadable and nothing in dmesg" does appear to be a continuation of that. -- With respect, Roman -- 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
