[LU-11011] checksum type can not be selected permanently

• Type: Improvement
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.13.0
• Labels: patch
• Assignee: Li Xi
• Reporter: Li Xi (Inactive)

Description

Some checksum types might not work correctly even though they are available
options and have the best speeds during test. In these circumstances, users
might want to use a certain checksum type which is known to be functional.
However, "lctl conf_param XXX-YYY.osc.checksum_type=ZZZ" won't help to enforce
a certain checksum type, because the selected checksum type is determined
during OSC connection, which will overwrite the LLOG parameter.

Following is the design of solving the problem:

To solve this problem, whenever a valid checksum type is set by "lctl
conf_param" or "lctl set_param", it is remembered as the perferred checksum
type for the OSC. During connection process, if that checksum type is
available, that checksum type will be selected as the RPC checksum type
regardless of its speed.

The semantics of interface /proc/fs/lustre/osc/*/checksum_type is changed for
a little bit. If a wrong checksum name is being written into this entry,
-EINVAL will be returned as before. If the written string is a valid checksum
name, even though the checksum type is not supported by this OSC/OST pair, the
checksum type will still be remembered as the perferred checksum type, and
return value will be -ENOTSUPP. Whenever connecting/reconnecting happens, if
perferred checksum type is availabe, it will be used for the RPC checksum.

Issue Links

• is related to: LU-10906 checksums parameter not persistent after reboot
• is related to: LU-14912 client picking other checksum type over T10PI

Comments

[Peter Jones]

Landed for 2.13

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/32349/
Subject: LU-11011 osc: add preferred checksum type support
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 9b6b5e4798281eceb45699431bc871eda6d968c4

[Li Xi]

> Some checksum types might not work correctly even though they are available options and have the best speeds during test.

This was not caused by Lustre problem.

A user found a problem of the default checksum type which has the best performance. I don't remember the details. I remember the checksum sometimes was calculated wrongly. The root cause might be a bug of the CPU or the kernel. Thus, the user wants to change the checksum type to another one which doesn't have the best performance. And a persistent configuration would be better than changing everytime when restarting the services.