Bug 1659487 - [GSS][RHEV: The mount logs of 'vmstore' volume are consuming all the space under /var/log]
Summary: [GSS][RHEV: The mount logs of 'vmstore' volume are consuming all the space un...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: bitrot
Version: rhgs-3.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: RHGS 3.5.0
Assignee: Raghavendra Bhat
QA Contact: Sweta Anandpara
URL:
Whiteboard:
Depends On:
Blocks: 1657798 1696806
TreeView+ depends on / blocked
 
Reported: 2018-12-14 14:12 UTC by nravinas
Modified: 2022-03-13 16:30 UTC (History)
15 users (show)

Fixed In Version: glusterfs-6.0-2
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-30 12:20:13 UTC
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:3249 0 None None None 2019-10-30 12:20:36 UTC

Comment 40 Yaniv Kaul 2019-04-09 11:53:57 UTC 
What's missing from upstream Gluster 6 (and now RHGS 3.5) to move this to MODIFIED?
Comment 46 Raghavendra Bhat 2019-06-24 15:12:44 UTC 
This does not require a doc text. The changes done are internal to the gluster process and not seen by the user directly. Still for the purpose of clarification, below is the changes made regarding this bug in the upstream patch https://review.gluster.org/#/c/glusterfs/+/21996/

* Before the above mentioned patch, bit-rot-stub xlator which is part of the glusterfsd brick process was sending its internal extended attribute (bad file xattr, version, signature etc) in the list of xattrs for fops such as getxattr, listxattr, readdirp, lookup. Ideally, only bad-file xattr should be sent back to higher layer (if the xattr is present which means file has been marked as bad), that too only in lookup.

Hence, apart from lookup, none of the other fops would send any of the internal bit-rot related xattrs to the higher layers. And even in lookup only bad file marker is sufficient. Higher layers should make any decisions based on that information (if at all needed).
Comment 48 SATHEESARAN 2019-07-03 10:55:30 UTC 
Raghavendra,

I see that there are 3 different issues reported in this bug:

1. Spurious metadata heal
2. Excessive heal specific logging.

Neither RHHI-V nor RHV-RHGS ( non-hyperconverged ) supports bit-rot.
With that in mind, can we qualify this patch with replica 3 + normal file workload ?
Comment 49 Raghavendra Bhat 2019-07-03 14:10:43 UTC 
Satheesaran,

The spurious metadata heal was caused because bit-rot specific xattrs were being sent to higher layers which caused AFR to trigger healing. The patch fixes that issue by not sending bit-rot specific xattrs in some calls (that it used to send before). So atleast from bit-rot perspective the issue is addressed. You can qualify this change for regular replica 3 + normal file workload.
Comment 56 errata-xmlrpc 2019-10-30 12:20:13 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:3249
Note You need to log in before you can comment on or make changes to this bug.