Re: btrfs on bcache

2013-12-20 Thread Henry de Valence
On Thu, Dec 19, 2013 at 2:04 PM, Fábio Pfeifer  wrote:
> Any update on this?
>
> I have here exactly the same issue. Kernel 3.12.5-1-ARCH, backing
> device 500 GB IDE, cache 24 GB SSD => /dev/bcache0
> On /dev/bcache I also have 2 subvolumes, / and /home. I get lots of
> messages in dmesg:

I also have this issue.

Also, this afternoon I experienced data corruption on my btrfs device
(checksum errors), which might or might not be related. I don't really
know how to determine the cause, but if anyone has suggestions they'd
be appreciated.

Cheers,
Henry de Valence
--
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


Itermittent data corruption and dmesg spam

2013-10-22 Thread Henry de Valence
Hi all,

Two questions:

First, I have a ton of lines in dmesg like

[  123.664465] incomplete page read in btrfs with offset 2048 and length 2048
[  123.835761] incomplete page read in btrfs with offset 512 and length 3584

What does this mean? I tried searching on Google but all I got was the commit 
that added the code that prints these messages. Should I be worried?

Second, I’m having some intermittent data corruption issues, and I’m not 
really sure how to pin down the cause. Sometimes, I’ll get errors trying to 
read a file due to a failed checksum, but when I run btrfs scrub, it reports 
that everything is OK. For instance, this time I booted, I get a line in dmesg 
saying

btrfs: bdev /dev/bcache0 errs: wr 0, rd 0, flush 0, corrupt 16, gen 0

but when I run btrfs scrub I get:

scrub status for 56118d27-c9a8-483c-afaa-e429d59884e9
 scrub started at Tue Oct 22 22:46:17 2013 and finished after 2802 seconds
 total bytes scrubbed: 426.03GB with 0 errors

My setup is a btrfs partition on a bcache device, which has a new-ish hard 
drive as the backing store and a partition on an older SSD as the cache. The 
bcache documentation suggests that sequential reads bypass the cache device. 
Is it possible that I have some bad blocks on my SSD, which cause the errors 
and data corruption, but the data corruption doesn’t show up with btrfs scrub 
because the disk accesses in the scrub are bypassing the cache?

Does anyone know how I could test this theory, or otherwise try to determine 
the source of the problems?

For what it’s worth, I ran smartctl on both my hard drive and my SSD, and it 
didn’t detect anything.

My btrfs version is Btrfs v0.20-rc1-358-g194aa4a on Linux 3.11.3 (Arch).

Thanks,
Henry de Valence

signature.asc
Description: This is a digitally signed message part.