[Bugs] [Bug 1170913] New: [AFR-V2] - Eliminate inodelks taken by shd during metadata self-heal in self-heal domain

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1170913

            Bug ID: 1170913
           Summary: [AFR-V2] - Eliminate inodelks taken by shd during
                    metadata self-heal in self-heal domain
           Product: GlusterFS
           Version: mainline
         Component: replicate
          Assignee: bugs at gluster.org
          Reporter: kdhananj at redhat.com
                CC: bugs at gluster.org, gluster-bugs at redhat.com



Description of problem:

The reason self-heal daemons first acquire full locks in self-heal domain in
AFR-V2, is to ensure that only one of them gets to enter the critical section
and do the healing of a file/directory.

Although this was being achieved before AFR-V2 by way of holding full locks in
xlator domain (the domain where normal modification FOPs take locks in the
clients' I/O path) until the given file/directory is healed, the disadvantage
with this approach was that the clients in the normal I/O path would be
required to wait until this file/dir is healed, and in cases where the
to-be-healed files are really large (think VM images), the clients would
perceive a hung file system with nothing working.

Therefore, to eliminate this, self-heal domain locks were introduced
exclusively for use by self-heal daemon.

However, metadata self-heal is a relatively fast operation (irrespective of how
big the file/directory is). Hence, it can possibly eliminate locking in
sh-domain and directly proceed with a blocking locks acquisition in xlator
domain, perform metadata healing (a bunch of getxattrs, setxattrs, removexattrs
and setattr), and a quick unlock on the held locks.

This way,
a. No two healers can concurrently perform metadata healing of a file/dir;
b. The clients themselves cannot enter the critical section either to modify
metadata while selfheal is in progress.
c. The clients in the normal i/o path do not have to be blocked for a really
long time to do metadata FOPs;

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


How reproducible:
N/A

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.