Hi-- On Fri, May 4, 2018 at 5:51 AM, Coly Li <colyli@xxxxxxx> wrote: > So far cache_sb.csum is defined as __u64, and it should be le64 or > __le64 as on-disk format. For on-disk format, we need something like > crc64_le() to calculate 64bits crc. There's two different things here-- the endianess of the CRC computation (this SHOULD NOT CHANGE between architectures or there will be inconsistent results, and is almost always little endian), and the endian-ness of the result-- this needs swapping. Only crc32 of the other CRC code in the kernel, or elsewhere, has BE/LE variants; all the other CRC routines produce a (8, 16, 32) bit quantity in native byte order. Yes, the final value after the computation needs to be byte-swapped (native to LE or BE) before writing to disk or sending over the network. CRC32 does because a few strange things (e.g. ATM, jbd2) do stuff on CRCs defined for bigger words as big-endian. Why is it not OK to just use a LE CRC like almost everything else (and that we already are) and byteswap the result? Seems the only thing missing in bcache is the swap of the CRC data itself before compare / before writing. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html