On Fri, 2015-11-13 at 07:05 +0000, Duncan wrote: > 8 TiB disks -- are those the disk-managed SMR "archive" disks I've > read > about on a number of threads? Yes... but... > If so, that hardware is almost certainly the cause, as they're known > to > be problematic on current kernels. While most filesystems (all?) > will > apparently go corrupt on them, it can remain invisible corruption for > quite some time on many of them, but btrfs with its checksums and etc > will tend to show up the problems far sooner, and there have been at > least 2-3 threads on the problem already, on this list. I think it's pretty unlikely that this is the reason. - I never saw any errors popping up from the lower driver levels (i.e. the ATA errors all those people saw), and I've regularly checked - I always did the checksum verification based on my own hashes stored in each file's XATTRS, without any error so far. - I wrote far more data (the device is nearly fully) without any error (XATTRs/hashes) than the time when most of these people noticed sever corruptions, which seemed to happen already after some GB. - I think it's pretty unlikely that all data (in terms of hashsums) would be okay, and that these corruptions would have just appeared in some of btrfs meta-data. I'm not sure why I don't suffer from these issues, probably because I run them only via USB/SATA bridges, which, while they're USB3.0, are probably too slow for these errors to pop up. See my comment: https://bugzilla.kernel.org/show_bug.cgi?id=93581#c70 Further, a small status update: As mentioned this night, I've kicked of a full run of verifying all of my XATTRs-set hashsums... (and these hashsums are basically all computed when the data is known to be valid, e.g. for DSLR pictures straight off the SD, etc.). In terms of numbers of files, that run is half through,... so far with only a handful of errors related to files where I've apparently forgot to set the sums. No errors (so far). So unless btrfs completely lost file entries (and I guess that wouldn't just affect the extent tree?), and I thus wouldn't verify these files at all or notice them missing,... everything seems fine, as far as I can tell, (so far). I'll basically just about to head of to get my backup disk, which I haven't at home... to see whether it also shows these fsck errors. So stay tuned. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
