Description of problem: If a client older than glusterfs-4.x (i.e. 3.x clients) accesses a volume which has the `fips-mode-rchecksum` volume option enabled, it can cause erroneous checksum computation/ unwanted behaviour during afr self-heal. This option is to be enabled only when all clients are also >=4.x Once https://review.gluster.org/#/c/glusterfs/+/22609/, which is targeted at gluster-7, is merged, any new volumes created will have the fips-mode-rchecksum volume option on by default. That makes it important to document explicitly in the release notes that this option is to be enabled only if all clients also >=gluster-4.x. Hence creating a place-holder BZ for the same.
https://review.gluster.org/#/c/glusterfs/+/22609/ is merged. Can we now document it? When can we remove this option altogether and have it as a default (and then remove all the gf_rsync_md5_checksum() code and friends) ?
(In reply to Yaniv Kaul from comment #1) > https://review.gluster.org/#/c/glusterfs/+/22609/ is merged. Can we now > document it? > I was targeting it for the glusterfs-7 release notes. > When can we remove this option altogether and have it as a default (and then > remove all the gf_rsync_md5_checksum() code and friends) ? Technically, we could do it today since 3.x is EOL and 4.1 onwards clients have the logic to check the dict for what type of checksum the server is sending and act accordingly. But people might use 3.x clients with 4.x or later servers 'as long as the mount succeeds', so maybe it is better to have it for some more time.
Hi Rinku, feel free to ping me if you need any inputs or if something is not clear in the bug description.
REVIEW: https://review.gluster.org/23330 (doc: documented about fips-mode-rchecksum) posted (#1) for review on release-7 by Rinku Kothiya
REVIEW: https://review.gluster.org/23330 (doc: documented about fips-mode-rchecksum) merged (#3) on release-7 by Rinku Kothiya