[Bugs] [Bug 1303177] New: Enhancement: Allow self-heal to continue from another daemon

bugzilla at redhat.com bugzilla at redhat.com
Fri Jan 29 18:57:11 UTC 2016


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

            Bug ID: 1303177
           Summary: Enhancement: Allow self-heal to continue from another
                    daemon
           Product: GlusterFS
           Version: 3.7.7
         Component: replicate
          Assignee: bugs at gluster.org
          Reporter: joe at julianfamily.org
                CC: bugs at gluster.org



When a self-heal is started, that client will continue to do the self-heal
until it's complete. If, however, that client is stopped (unmounted client,
restarted shd, etc), the heal starts over from the beginning. When you're
healing files that take many days to heal, this behavior is undesirable.

Since the bricks already have the lock data that shows how far along the heal
is, there should be a way to keep track (metadata? brick memory?) and allow
another client to continue.

If this is integrated with throttling, this could even be a pooled process
queue that could be picked up by whichever shd has free tokens, allowing the
entire cluster to progress the heal and, potentially, take over the background
heal from a fuse client.

This should be controllable from the cli where the admin could stop the
self-heal from continuing on a specific client and it would continue from
another shd, optionally the specific shd could be specified as part of the
instruction. This would be useful where the fuse client begins a background
self-heal across the slower client network, but the admin wants the self-heal
to be run by a shd across a faster backend connection.

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


More information about the Bugs mailing list