How can I tell what AFR version a cluster is using for self-heal? The reason I ask is that I have a two-node replicated 3.7.8 cluster (no arbiters) which has locking behavior during self-heal which looks very similar to that of AFRv1 (only heals one file at a time per self-heal daemon, appears to lock the full inode while it's healing it instead of just ranges, etc.), but I don't know how I would check the version to confirm that suspicion. I've seen mention of needing to explicitly enable AFRv2 when upgrading Gluster from an older version, and this cluster was one that started at an older Gluster version and was upgraded in accordance with the upgrade docs, but I cannot seem to find any documentation on enabling newer versions of AFR or even checking which one I'm running at. cluster.op-version for this cluster is currently at 30603, and both nodes are CentOS 7 running Gluster 3.7.8. Any help would be appreciated. Thanks! Warm Regards, Kyle Maas
On 02/25/2016 11:36 PM, Kyle Maas wrote:> How can I tell what AFR version a cluster is using for self-heal?If all your servers and clients are 3.7.8, then they are by default running afr-v2. Afr-v2 was a re-write of afr that went in for 3.6., so any gluster package from then on has this code, you don't need to explicitly enable anything.> > The reason I ask is that I have a two-node replicated 3.7.8 cluster (no > arbiters) which has locking behavior during self-heal which looks very > similar to that of AFRv1 (only heals one file at a time per self-heal > daemon, appears to lock the full inode while it's healing it instead of > just ranges, etc.),Both v1 and v2 use range locks while healing a given file, so clients shouldn't block when heals happen. What is the problem you're facing? Are your clients also at 3.7.8? -Ravi> but I don't know how I would check the version to > confirm that suspicion. I've seen mention of needing to explicitly > enable AFRv2 when upgrading Gluster from an older version, and this > cluster was one that started at an older Gluster version and was > upgraded in accordance with the upgrade docs, but I cannot seem to find > any documentation on enabling newer versions of AFR or even checking > which one I'm running at. cluster.op-version for this cluster is > currently at 30603, and both nodes are CentOS 7 running Gluster 3.7.8. > > Any help would be appreciated. Thanks! > > Warm Regards, > Kyle Maas > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://www.gluster.org/mailman/listinfo/gluster-users
----- Original Message -----> From: "Kyle Maas" <kyle at virtualinterconnect.com> > To: gluster-users at gluster.org > Sent: Thursday, February 25, 2016 11:36:53 PM > Subject: [Gluster-users] AFR Version used for self-heal> How can I tell what AFR version a cluster is using for self-heal?> The reason I ask is that I have a two-node replicated 3.7.8 cluster (no > arbiters) which has locking behavior during self-heal which looks very > similar to that of AFRv1 (only heals one file at a time per self-heal > daemon, appears to lock the full inode while it's healing it instead of > just ranges, etc.), but I don't know how I would check the version to > confirm that suspicion. I've seen mention of needing to explicitly > enable AFRv2 when upgrading Gluster from an older version, and this > cluster was one that started at an older Gluster version and was > upgraded in accordance with the upgrade docs, but I cannot seem to find > any documentation on enabling newer versions of AFR or even checking > which one I'm running at. cluster.op-version for this cluster is > currently at 30603, and both nodes are CentOS 7 running Gluster 3.7.8.> Any help would be appreciated. Thanks!So if you bring one of the replicas down, create a file, and check its extended attributes from the backend (`getfattr -d -m . -e hex <path-to-the-file-from-the-brick-path-that-is-online`), do you see this appearing in the list: trusted.afr.dirty=0x000000000000000000000000 ? -Krutika> Warm Regards, > Kyle Maas> _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://www.gluster.org/mailman/listinfo/gluster-users-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20160225/4f353367/attachment.html>