summaryrefslogtreecommitdiffstats
path: root/xlators/storage
diff options
context:
space:
mode:
authorAtin Mukherjee <amukherj@redhat.com>2019-04-09 19:02:53 +0530
committerRaghavendra G <rgowdapp@redhat.com>2019-07-08 05:10:03 +0000
commit4c44c47a40910c70e7d22d2bc6b7c21b88e3296b (patch)
tree56dae3b0d69340ac7649dbe8e5dbd208f386ffd6 /xlators/storage
parent99d210a704d2e85c95fac5edcf435bd059aad368 (diff)
quick-read: rename cache-invalidation key to avoid redundant keys
With group-metadata-cache group profile settings performance.cache-invalidation option when turned on enables both md-cache and quick-read xlator's cache-invalidation feature. While the intent of the group-metadata-cache is to set md-cache xlator's cache-invalidation feature, quick-read xlator also gets affected due to the same. While md-cache feature and it's profile existed since release-3.9, quick-read cache-invalidation was introduced in release-4 and due to this op-version mismatch on any cluster which is >= glusterfs-4 when this group profile is applied it breaks backward compatibility with the old clients. The proposed fix here is to rename the key in quick-read to 'quick-read-cache-invalidation' so that both these features have distinct identification. While this brings in by itself a backward compatibility challenge where this feature is enabled in an existing cluster and when the same is upgraded to a version where this change exists, it will lead to an unidentified old key. But as a workaround we can always ask users upgrading to release-7 version to turn off this option, upgrade the cluster and turn it back on with the new key. This needs to be documented once the patch is accepted. Fixes: bz#1698042 Change-Id: I30422ba6496208e21191a8d78ad29b2e21078664 Signed-off-by: Atin Mukherjee <amukherj@redhat.com> Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
Diffstat (limited to 'xlators/storage')
0 files changed, 0 insertions, 0 deletions