[Gluster-devel] add-brick

Anand Avati anand.avati at gmail.com
Mon Aug 20 08:47:40 UTC 2012


Something like this: (not tested at all)

diff --git a/xlators/cluster/dht/src/dht-common.c
b/xlators/cluster/dht/src/dht-common.c
index 4d8d326..0f8322f 100644
--- a/xlators/cluster/dht/src/dht-common.c
+++ b/xlators/cluster/dht/src/dht-common.c
@@ -191,7 +191,7 @@ dht_discover_complete (xlator_t *this, call_frame_t
*discover_frame)
                                 "ENOENT errors: %d)", local->loc.path,
                                 (ret < 0) ? "yes" : "no", (ret > 0) ? ret
: 0);
                         op_errno = EINVAL;
-                        goto out;
+                        goto selfheal;
                 }

                 dht_layout_set (this, local->inode, layout);
@@ -206,6 +206,12 @@ out:
                           NULL);

         return ret;
+selfheal:
+        FRAME_SU_DO (frame, dht_local_t);
+        uuid_copy (local->loc.gfid, local->gfid);
+        ret = dht_selfheal_directory (frame, dht_lookup_selfheal_cbk,
+                                      &local->loc, layout);
+       return 0;
 }


Inside dht_selfheal_directory and beyond we would need changes to make it
work specially for nameless loc_t where it would not try to create missing
dirs but only fix layout.

All this is necessary only for fixing 1-brick -> 2-brick kind of add-brick
(which should be broken even on Linux now)

Avati

On Mon, Aug 20, 2012 at 12:38 AM, Emmanuel Dreyfus <manu at netbsd.org> wrote:

> On Sun, Aug 19, 2012 at 06:38:48AM -0700, Anand Avati wrote:
> > I now realize that if you re-refer an inode before it is timed out in the
> > kernel (and LOOKUP is sent), then the code path
> > hitting fuse_resolve_gfid_cbk might reach this. We need to call
> > dht_self_heal in dht_discover_cbk if layout requires healing.
>
> There are many flavors of dht_selfheal_*(), the change is not
> straightforward.  Would you have a patch (even untested, just to
> give the direction)?
>
> --
> Emmanuel Dreyfus
> manu at netbsd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120820/534b8687/attachment-0003.html>


More information about the Gluster-devel mailing list