Description of problem: Shard xlator creates new shards using MKNOD fop during inode writes. But bitrot does not have mknod implemented. Writevs on new shards is failing in bitrot with EINVAL, with the following message appearing in the brick logs: [2015-05-15 07:49:20.836176] E [bit-rot-stub.c:989:br_stub_writev] 0-dis-bitrot-stub: failed to get the inode context for the inode c007285e-c448-455a-a9b5-6c1ca011c3e0 Turns out inode ctx for a file is set by bitrot xlator in create callback (alone). And it is read in br_stub_writev(). Due to the absence of a br_stub_mknod() fop through which shards are created, a subsequent writes on these shards leads to inode_ctx_get() failure leading to bit-rot xlator unwinding the fop with EINVAL. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
REVIEW: http://review.gluster.org/10790 (features/bit-rot-stub: implement mknod fop) posted (#2) for review on master by Raghavendra Bhat (raghavendra)
REVIEW: http://review.gluster.org/10790 (features/bit-rot-stub: implement mknod fop) posted (#3) for review on master by Venky Shankar (vshankar)
REVIEW: http://review.gluster.org/10790 (features/bit-rot-stub: implement mknod fop) posted (#5) for review on master by Venky Shankar (vshankar)
REVIEW: http://review.gluster.org/10790 (features/bit-rot-stub: implement mknod fop) posted (#6) for review on master by Venky Shankar (vshankar)
COMMIT: http://review.gluster.org/10790 committed in master by Venky Shankar (vshankar) ------ commit 37cc99fc3a991241df49133902928bd789d95066 Author: Raghavendra Bhat <raghavendra> Date: Fri May 15 14:10:48 2015 +0530 features/bit-rot-stub: implement mknod fop With the absence of mknod() fop implementation in bitrot stub, further operations that trigger versioning resulted in crashes as they expect the inode context to be valid. Therefore, this patch implements mknod() following similar simantics to fops such as create(). Furthermore, bitrot stub test C program is fixed to stop lying and validate obj versions according to the versioning protocol. Change-Id: If76f252577445d1851d6c13c7e969e864e2183ef BUG: 1221914 Original-Author: Raghavendra Bhat <raghavendra> Signed-off-by: Venky Shankar <vshankar> Reviewed-on: http://review.gluster.org/10790 Tested-by: NetBSD Build System <jenkins.org> Tested-by: Gluster Build System <jenkins.com>
The required changes to fix this bug have not made it into glusterfs-3.7.1. This bug is now getting tracked for glusterfs-3.7.2.
Unfortunately glusterfs-3.7.2 did not contain a code change that was associated with this bug report. This bug is now proposed to be a blocker for glusterfs-3.7.3.
This bug has been filed on the master branch and the change has already been merged into master. This bug shouldn't be blocking 3.7.x releases. Removing the `glusterfs-3.7.3` block.
Fix for this BZ is already present in a GlusterFS release. You can find clone of this BZ, fixed in a GlusterFS release and closed. Hence closing this mainline BZ as well.
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.8.0, please open a new bug report. glusterfs-3.8.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://blog.gluster.org/2016/06/glusterfs-3-8-released/ [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user