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

[Wang Shilong <wangsl.fnst@cn.fujitsu.com>]

On 02/20/2014 08:38 PM, Wang Shilong wrote:
> On 02/20/2014 07:25 PM, Sebastian Ochmann wrote:
>> Hello,
>>
>>>     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.
This should be related to btrfs free space cache, it is designed as 
nocow without
checksums.

Thanks,
Wang
>>>
>>> Did you enable nodatacow option? if  nodatacow option is enabled,
>>> data checksums will be also disabled at the same time.
> [SNIP]
>
> So i have found why we have such strange things from debugging, you 
> can have a try as the
> following steps:
>
> # mkfs.btrfs -f /dev/sda9
> # mount /dev/sda9 /mnt
> # btrfs scrub start -BR /mnt
>
> scrub done for 02dd3326-959f-4602-9baa-aa9ed99ac2e5
>     scrub started at Thu Feb 20 20:31:46 2014 and finished after 0 
> seconds
>     data_extents_scrubbed: 1
>     tree_extents_scrubbed: 16
>     data_bytes_scrubbed: 65536
>     tree_bytes_scrubbed: 262144
>     read_errors: 0
>     csum_errors: 0
>     verify_errors: 0
>     no_csum: 16 ---------------------->not equal 0 for a newly mkfs.
>     csum_discards: 0
>     super_errors: 0
>     malloc_errors: 0
>     uncorrectable_errors: 0
>     unverified_errors: 0
>     corrected_errors: 0
>     last_physical: 467140608
>
> # btrfs-debug-tree /dev/sda9
>
> By debuging tree, we found there is a EXTENT_ITEM in extent tree for 
> newly
> mkfs filesystem which we have written anything yet.
>
>  item 2 key (12582912 EXTENT_ITEM 65536) itemoff 16182 itemsize 53
>                 extent refs 1 gen 5 flags 1
>                 extent data backref root 1 objectid 256 offset 0 count 1
> item 3 key (12582912 BLOCK_GROUP_ITEM 8388608) itemoff 16158 itemsize 24
>
> At the same time, Let's see Csum tree debug output:
>
> checksum tree key (CSUM_TREE ROOT_ITEM 0)
> leaf 29425664 items 0 free space 16283 generation 4 owner 7
> fs uuid 02dd3326-959f-4602-9baa-aa9ed99ac2e5
>
> So there is not corresponding checksum item for that DATA extent item..
> This can explain why scrub output no_sum count!
>
> For reasons, It may be reserved data space without checksum for other 
> purpose!
> So if this is true, i don't think this is harm for common users unless 
> it is designed
> unexpectedly!
>
> Thanks,
> Wang
>>
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>