Red Hat Bugzilla – Bug 1313131
[New] - quarantine folder becomes empty and bitrot status does not list any files which are corrupted
Last modified: 2016-04-19 03:21:27 EDT
REVIEW: http://review.gluster.org/13552 (features/bitrot: do not remove the quarantine handle in forget) posted (#1) for review on release-3.7 by Venky Shankar (email@example.com)
REVIEW: http://review.gluster.org/13552 (features/bitrot: do not remove the quarantine handle in forget) posted (#2) for review on release-3.7 by Venky Shankar (firstname.lastname@example.org)
COMMIT: http://review.gluster.org/13552 committed in release-3.7 by Venky Shankar (email@example.com)
Author: Raghavendra Bhat <firstname.lastname@example.org>
Date: Tue Feb 16 20:22:36 2016 -0500
features/bitrot: do not remove the quarantine handle in forget
If an object is marked as bad, then an entry is corresponding to the
bad object is created in the .glusterfs/quarantine directory to help
scrub status. The entry name is the gfid of the corrupted object.
The quarantine handle is removed in below 2 cases.
1) When protocol/server revceives the -ve lookup on an entry whose inode
is there in the inode table (it can happen when the corrupted object
is deleted directly from the backend for recovery purpose) it sends a
forget on the inode and bit-rot-stub removes the quarantine handle in
upon getting the forget.
refer to the below commit
2) When bit-rot-stub itself realizes that lookup on a corrupted object
has failed with ENOENT.
But with step1, there is a problem when the bit-rot-stub receives forget
due to lru limit exceeding in the inode table. In such cases, though the
corrupted object is not deleted (either from the mount point or from the
backend), the handle in the quarantine directory is removed and that object
is not shown in the bad objects list in the scrub status command.
So it is better to follow only 2nd step (i.e. bit-rot-stub removing the handle
from the quarantine directory in -ve lookups). Also the handle has to be removed
when a corrupted object is unlinked from the mount point itself.
Original author: Raghavendra Bhat <email@example.com>
Signed-off-by: Kotresh HR <firstname.lastname@example.org>
Smoke: Gluster Build System <email@example.com>
NetBSD-regression: NetBSD Build System <firstname.lastname@example.org>
CentOS-regression: Gluster Build System <email@example.com>
Reviewed-by: Venky Shankar <firstname.lastname@example.org>
(cherry picked from commit 2102010edab355ac9882eea41a46edaca8b9d02c)
Tested-by: Venky Shankar <email@example.com>
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.9, please open a new bug report.
glusterfs-3.7.9 has been announced on the Gluster mailinglists , packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist  and the update infrastructure for your distribution.