Re: [PATCH] btrfs-progs: Output proper csum string if csum mismatch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 20, 2020 at 05:32:05PM +0800, Qu Wenruo wrote:
> Introduce a new helper, csum_to_string(), to convert binary csum to
> string.
> 
> And use it in check_extent_csums(), so that
> "btrfs check --check-data-csum" could report the following human
> readable output:
>   mirror 1 bytenr 13631488 csum 0x13fec125 expected csum 0x98757625
> 
> Other than the original octane one:
>   mirror 1 bytenr 13631488 csum 19 expected csum 152
> 
> It also has the extra handling for 32 bytes csum (e.g. SHA256).
> For such long csum, it needs 66 characters (+2 for "0x") to just output
> one hash, so this function would truncate them into the following
> format:
>  0xaabb...ccdd
>     |       \- The tailing 2 bytes
>     \--------- The leading 2 bytes

Kernel prints the whole checksum and also 2 on one line,
btrfs_print_data_csum_error. The short version is ok for quick comparing
but for consistency do you think it's too bad to print the whole
checksum? Eg. when I see errors, copy&paste the checksum and can cross
check with the kernel messages/logs.



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux