regards Aravinda On Wednesday 21 September 2016 03:53 PM, Ravishankar N wrote: > On 09/21/2016 03:34 PM, Aravinda wrote: >> Hi, >> >> We have following SPLIT_BRAIN events >> >> EVENT_AFR_SPLIT_BRAIN, "subvol=%s;msg=file type mismatch;gfid=%s;ia_type-%d=%s;ia_type-%d=%s" >> EVENT_AFR_SPLIT_BRAIN, "subvol=%s;msg=gfid mismatch. Skipping conservative merge.;file=<gfid:%s>/%s>;count=2;child-%d=%s;gfid-%d=%s;child-%d=%s;gfid-%d=%s", >> EVENT_AFR_SPLIT_BRAIN, "subvol=%s;msg=file type mismatch. Skipping conservative merge;file=<gfid:%s>/%s>;count=2;child-%d=%s;type-%d=%s;child-%d=%s;type-%d=%s", >> EVENT_AFR_SPLIT_BRAIN, "subvol=%s;msg=file type mismatch;file=<gfid:%s>/%s;count=2;child-%d=%s;type-%d=%s;child-%d=%s;type-%d=%s" >> EVENT_AFR_SPLIT_BRAIN, "subvol=%s;msg=gfid mismatch;file=<gfid:%s>/%s;count=2;child-%d=%s;gfid-%d=%s;child-%d=%s;gfid-%d=%s" >> >> Message keys are not same even though Split brain type is same. For example, >> >> EVENT_AFR_SPLIT_BRAIN, "subvol=%s;msg=file type mismatch;gfid=%s;ia_type-%d=%s;ia_type-%d=%s" >> EVENT_AFR_SPLIT_BRAIN, "subvol=%s;msg=file type mismatch;file=<gfid:%s>/%s;count=2;child-%d=%s;type-%d=%s;child-%d=%s;type-%d=%s" >> >> We can split these events into two types.(Message included as EVENT name itself, so that no separate msg is required.) >> >> EVENT_AFR_SPLIT_BRAIN_FILE_TYPE_MISMATCH, "subvol=%s;file=<gfid:%s>/%s;count=2;child-%d=%s;type-%d=%s;child-%d=%s;type-%d=%s" >> EVENT_AFR_SPLIT_BRAIN_GFID_MISMATCH, "subvol=%s;file=<gfid:%s>/%s>;count=2;child-%d=%s;gfid-%d=%s;child-%d=%s;gfid-%d=%s" >> >> Let me know your thoughts. >> > > I think it is better to retain one EVENT type for split-brains. Otherwise we need to keep on adding different EVENT types for example when we need to propagate data split-brain or metadata split-brain etc. > The msg=<message> also gives us a way to specific a more verbose message that is immediately available to the consumer, should they decide to parse it. Also, for all types of split-brains, there has to be a remedial action (i.e. resolving the split-brains) required by the admin. Having to monitor only one EVENT type for all split-brains would make it easier is what I feel. If it is one event type, then I would prefer "type" instead of msg. (type can be gfid|file|data|meta etc). Descriptive message is not required since these APIs are consumed programatically, free text and non uniform key names breaks the parsing. > > -Ravi
REVIEW: http://review.gluster.org/15550 (afr: Modifications to afr events) posted (#1) for review on master by Ravishankar N (ravishankar)
COMMIT: http://review.gluster.org/15550 committed in master by Pranith Kumar Karampuri (pkarampu) ------ commit f6a3c541941df6fd19ef57185aca5c4bcec2dec3 Author: Ravishankar N <ravishankar> Date: Fri Sep 23 15:16:46 2016 +0530 afr: Modifications to afr events Modified afr event message to add a 'type' key as detailed in the BZ. Also added events for data and metadata split-brain. Change-Id: I8156674b4b6a501499fc10fd68e05115fdaef3e4 BUG: 1378072 Signed-off-by: Ravishankar N <ravishankar> Reviewed-on: http://review.gluster.org/15550 Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Pranith Kumar Karampuri <pkarampu>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.10.0, please open a new bug report. glusterfs-3.10.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://lists.gluster.org/pipermail/gluster-users/2017-February/030119.html [2] https://www.gluster.org/pipermail/gluster-users/