Object versions is not incremented some times Description of problem: ======================= Object version should be incremented on write but for few files Object version is not incremented always Version-Release number of selected component (if applicable): ============================================================= 0.803.gitf64666f.el6.x86_64 How reproducible: ================= always Steps to Reproduce: =================== 1.created Distributed volume having 3 bricks. start and mount that volume 2. enable bitrot for that volume 3. from 3 FUSE mount, touch few files at same time. minimum value for Object version should be 1, considering race. [root@rhs-client37 v21]# touch f{1..10} 4. write to that file from 3 mount at same time. [root@rhs-client37 v21]# for i in {1..10}; do echo "abc" >> f$i ; done 5. check version for that file. Actual results: =============== sometimes version is not incremented and remains 1. [root@rhs-client44 ~]# getfattr -d -m . -e hex /pavanbrick6/br*/v21/f1 getfattr: Removing leading '/' from absolute path names # file: pavanbrick6/br1/v21/f1 trusted.afr.BitRot1-client-0=0x000000000000000000000000 trusted.afr.BitRot1-client-1=0x000000000000000000000000 trusted.afr.BitRot1-client-2=0x000000000000000000000000 trusted.afr.dirty=0x000000000000000000000000 trusted.gfid=0xd38e0fc8b1b249ac8f9fbf4b557b3f37 trusted.glusterfs.bit-rot.signature=0xff000000000000000000000000000000 trusted.glusterfs.bit-rot.version=0x01000000000000005514077f0006311c # file: pavanbrick6/br2/v21/f1 trusted.afr.BitRot1-client-0=0x000000000000000000000000 trusted.afr.BitRot1-client-1=0x000000000000000000000000 trusted.afr.BitRot1-client-2=0x000000000000000000000000 trusted.afr.dirty=0x000000000000000000000000 trusted.gfid=0xd38e0fc8b1b249ac8f9fbf4b557b3f37 trusted.glusterfs.bit-rot.signature=0xff000000000000000000000000000000 trusted.glusterfs.bit-rot.version=0x01000000000000005514077f000759a8 # file: pavanbrick6/br3/v21/f1 trusted.afr.BitRot1-client-0=0x000000000000000000000000 trusted.afr.BitRot1-client-1=0x000000000000000000000000 trusted.afr.BitRot1-client-2=0x000000000000000000000000 trusted.afr.dirty=0x000000000000000000000000 trusted.gfid=0xd38e0fc8b1b249ac8f9fbf4b557b3f37 trusted.glusterfs.bit-rot.signature=0xff000000000000000000000000000000 trusted.glusterfs.bit-rot.version=0x01000000000000005514077f00088684 Expected results: ================ Version should be anything between 2 to 5. (considering previous version was 1)
REVIEW: http://review.gluster.org/10117 (features/bitrot-stub: Enhancement to versioning protocol) posted (#1) for review on master by Venky Shankar (vshankar)
REVIEW: http://review.gluster.org/10117 (features/bitrot-stub: Enhancement to versioning protocol) posted (#2) for review on master by Venky Shankar (vshankar)
REVIEW: http://review.gluster.org/10117 (features/bitrot-stub: Enhancement to versioning protocol) posted (#3) for review on master by Venky Shankar (vshankar)
REVIEW: http://review.gluster.org/10117 (features/bitrot-stub: Enhancement to versioning protocol) posted (#4) for review on master by Venky Shankar (vshankar)
COMMIT: http://review.gluster.org/10117 committed in master by Vijay Bellur (vbellur) ------ commit 2dfc36811337666c26e42c13f19eb59a7cef674f Author: Venky Shankar <vshankar> Date: Mon Mar 30 21:46:25 2015 +0530 features/bitrot-stub: Enhancement to versioning protocol .. and potential bug fixes / memleak. While assigning initial version to an object, both extended attributes (namely, ongoing version and the default signing version) were persisted. This is optimized to just persist the ongoing version along with safe handling of xattr request(s) in it's absence. This is better than the earlier approach as the two xattr sets were not atomic anyway (allowing a request to sneak in between between two set operations). This also allows to perform sanity checks on objects during lookup()/getxattr(): objects with missing ongoing version but presence of signature are possible candidates of tampering (and catching implementation bugs). There were couple of instances in the code where versioning xattrs were incorrectly removed before in-memory versions were initialized, which have been fixed with this patch. A memory leak in the IPC code path is also fixed. Change-Id: I01c690ccfe7156a883582275f40f79a7c10c0900 BUG: 1207054 Signed-off-by: Venky Shankar <vshankar> Reviewed-on: http://review.gluster.org/10117 Reviewed-by: Raghavendra Bhat <raghavendra> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Vijay Bellur <vbellur>
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.7.0, please open a new bug report. glusterfs-3.7.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://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939 [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user