summaryrefslogtreecommitdiffstats
path: root/rpc
diff options
context:
space:
mode:
authorAshish Pandey <aspandey@redhat.com>2019-03-18 12:54:54 +0530
committerAshish Pandey <aspandey@redhat.com>2019-04-09 05:27:52 +0000
commitc5bc21ebbc10248848b372db34a33a0fcb9ae2ae (patch)
treea3313e5ef6543bdb256507db3c39af6e435a69fc /rpc
parent381e7603d9e8ff807e691b1d9272f050f341d2c6 (diff)
cluster/ec: Fix handling of heal info cases without locks
When we use heal info command, it takes lot of time as in some cases it takes lock on entries to find out if the entry actually needs heal or not. There are some cases where we can avoid these locks and can conclude if the entry needs heal or not. 1 - We do a lookup (without lock) on an entry, which we found in .glusterfs/indices/xattrop, and find that lock count is zero. Now if the file contains dirty bit set on all or any brick, we can say that this entry needs heal. 2 - If the lock count is one and dirty is greater than 1, then it also means that some fop had left the dirty bit set which made the dirty count of current fop (which has taken lock) more than one. At this point also we can definitely say that this entry needs heal. This patch is modifying code to take into consideration above two points. It is also changing code to not to call ec_heal_inspect if ec_heal_do was called from client side heal. Client side heal triggeres heal only when it is sure that it requires heal. [We have changed the code to not to call heal for lookup] updates bz#1697764 Change-Id: I7f09f0ecd12f65a353297aefd57026fd2bebdf9c Signed-off-by: Ashish Pandey <aspandey@redhat.com> (cherry picked from commit da47caf2405c08c9abafc4a55525a8b2c2dd5bb8)
Diffstat (limited to 'rpc')
0 files changed, 0 insertions, 0 deletions