On Jan 5, 2014, at 2:17 PM, Sulla <su...@gmx.at> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear Chris! > > Certainly: I have 3 HDDs, all of which WD20EARS.
These drives don't have a configurable SCT ERC, so you need to modify the SCSI block layer timeout: echo 120 >/sys/block/sdX/device/timeout You also need to schedule regular scrubs at the md level as well. echo check > /sys/block/mdX/md/sync_action cat /sys/block/mdX/mismatch_cnt More info about this is in man 4 md, and on the linux-raid list. > > 3904907520 blocks super 1.2 level 5, 8k chunk, algorithm 2 [3/3] [UUU] OK so 8KB chunk, 16KB full stripe, so that doesn't apply to what I was thinking might be the case. The workload is presumably small file sizes, like a mail server? > any other information I can supply? I'm not a developer, I don't know if this problem is known or maybe fixed in a newer kernel than 3.11.0 - which has been around for 5-6 months. I think the main suggestion is to try a newer kernel, granted with the configuration of md, lvm, and btrfs you have three layers that will likely have kernel changes. I'd make sure you have backups. While this layout is valid and should work, it's also probably less common and therefore less tested. Usually in case of blocking devs want to see sysrq+w issued. The setup is dmesg -n7, and enable sysrq functions. Then reproduce the block, and during the block issue w to the sysrq trigger, then capture dmesg contents and post the block and any other nearby btrfs messages. https://www.kernel.org/doc/Documentation/sysrq.txt Chris Murphy-- 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
