Bug 1463154 - RFE:heal deamon must not scan entries when a brick is still down, hence not wasting cpu cycles
RFE:heal deamon must not scan entries when a brick is still down, hence not w...
Status: ASSIGNED
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: disperse (Show other bugs)
3.3
Unspecified Unspecified
medium Severity high
: ---
: ---
Assigned To: Ashish Pandey
nchilaka
: FutureFeature, ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-20 05:07 EDT by nchilaka
Modified: 2017-09-28 13:42 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description nchilaka 2017-06-20 05:07:50 EDT
Description of problem:
====================
When a brick is down and heals are pending, there is no point scanning all the entries of indices xattrops and then figuring out the sink brick is still down, as this means wasted cpu cycles.
Suppose in  a 1x(4+2) volume , one brick is down, and a user created or modified say 1million files, the self healdeamon must not scroll/scan through all the pending heal entries in indices/xattrops and then decide not to heal as sink is still down.
Instead it can check if sink is still down and then only scan indices/xattrops

yes there can be cases where the down brick is up and another brick went down, so we should consider all these cases
Hence proposing as an RFE



Version-Release number of selected component (if applicable):
======
3.8.4-28

Steps to Reproduce:
1.create a 1x(4+2) volume
2.bring down b1
3.create 1million or say even 1lakh files

heal deamon now scans periodically all the entries in xattrops even when brick is down, which is of no use


Actual results:


Expected results:


Additional info:

Note You need to log in before you can comment on or make changes to this bug.