Wang Shilong posted on Thu, 20 Feb 2014 18:51:10 +0800 as excerpted: > On 02/20/2014 06:31 PM, Duncan wrote: >> Sebastian Ochmann posted on Wed, 19 Feb 2014 13:58:17 +0100 as >> excerpted: >> >>> So my question is, why does scrub show a high (i.e. non-zero) value >>> for no_csum? I never enabled nodatasum or a similar option.
> Did you enable nodatacow option? if nodatacow option is enabled, > data checksums will be also disabled at the same time. I have not. Everything here is standard checksummed COW, which is why I wondered why I was seeing the no_csum results. Tho in my case there's few enough I thought it might have been triggered by some other abnormality. (In particular, I was suspending-to-ram for awhile, and if I left the system suspended too long, the disks wouldn't wake up fast enough on resume and one of the raid1 pair would often drop out, forcing the filesystem to read-only and generally a pretty quick reboot, after which I'd have to do a scrub to sync the raid1 back up. I had guessed the no- csum instances might have been half-written at the suspend, but it bothered me. That was a couple kernels ago, tho. I decided to quit risking the suspend-to-ram since I was sometimes having to reboot anyway and I did end up with a file or two corrupted (even after scrub) as a result, so I've not had that issue or had any other scrub errors in some months now. I've thought I should try it again and see if it works better now, but I haven't done so yet.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
