Description of problem: commit c93c433 introduces signing of objects during write/truncate [first modification]. This avoids signing files which were never modified after creation. But, bitrot daemon sapwns a filesystem crawler (one top-down scan of the filesystem) that triggers signing of files which may have got missed in the last run (due to disabling bitrot and other scenarios). Triggering signing does not take into account the file size and hence triggers signing for empty files. Fix: The "oneshot" crawler needs to take into account the file size to counter this issue. Moreover, this check needs to be done *only* when an object has no bitrot extended attributed (version and signature). This check is required to handle truncates. Although harmless, this situation can be avoided with some minor modifications. Version-Release number of selected component (if applicable): mainline How reproducible: always Steps to Reproduce: 1. Create a Gluster volume and enable bitrot 2. create some empty files 3. before the files can be signed restart bitrot daemon Actual results: Empty files are signed Expected results: Since bitrot daemon signs files only on modification, empty files need not be signed. Additional info: None
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.
REVIEW: http://review.gluster.org/10947 (features/bit-rot: check for both inmemory and ondisk staleness) posted (#2) for review on master by Raghavendra Bhat (raghavendra)
REVIEW: http://review.gluster.org/10947 (features/bit-rot: check for both inmemory and ondisk staleness) posted (#3) for review on master by Venky Shankar (vshankar)
REVIEW: http://review.gluster.org/10947 (features/bit-rot: check for both inmemory and ondisk staleness) posted (#4) for review on master by Venky Shankar (vshankar)
REVIEW: http://review.gluster.org/10947 (features/bit-rot: check for both inmemory and ondisk staleness) posted (#5) for review on master by Raghavendra Bhat (raghavendra)
COMMIT: http://review.gluster.org/10947 committed in master by Venky Shankar (vshankar) ------ commit 60b6e5d2c3442ea0f7f85374d6613cd0dd76604c Author: Raghavendra Bhat <raghavendra> Date: Wed May 27 17:00:36 2015 +0530 features/bit-rot: check for both inmemory and ondisk staleness * Let bit-rot stub check both on disk ongoing version, signed version xattrs and the in memory flags in the inode and then decide whether the inode is stale or not. This information is used by one shot crawler in BitD to decide whether to trigger the sign for the object or skip it. NOTE: The above check should be done only for BitD. For scrubber its still the old way of comparing on disk ongoing version with signed version. * BitD's one shot crawler should not sign zero byte objects if they do not contain signature. (Means the object was just created and nothing was written to it). Change-Id: I6941aefc2981bf79a6aeb476e660f79908e165a8 BUG: 1224611 Signed-off-by: Raghavendra Bhat <raghavendra> Reviewed-on: http://review.gluster.org/10947 Reviewed-by: Venky Shankar <vshankar> Tested-by: Venky Shankar <vshankar> Tested-by: Gluster Build System <jenkins.com>
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