Re: Meaning of "no_csum" field when scrubbing with -R option

[Duncan <1i5t5.duncan@cox.net>]

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