[Gluster-devel] [RFC] Improved distribution

[Anand Avati]

On Tue, Apr 17, 2012 at 8:20 AM, Jeff Darcy <jdarcy at redhat.com> wrote:

> On Tue, 17 Apr 2012 11:14:21 -0400 (EDT)
> Kaleb Keithley <kkeithle at redhat.com> wrote:
>
> > ISTR Avati and/or Vijay telling us — when we were in BLR — that the
> > hash of the filename is salted with the hash of the pathname up to,
> > but not including the filename.
> >
> > Am I misremembering that? (Of course I haven't looked at the code.)
>
> I just did, and if there's anything but the name included I'm missing
> it.  Here's the DHT function that computes the hash.
>
>  73 int
>  74 dht_hash_compute (int type, const char *name, uint32_t *hash_p)
>  75 {
>  76         char     *rsync_friendly_name = NULL;
>  77
>  78         MAKE_RSYNC_FRIENDLY_NAME (rsync_friendly_name, name);
>  79
>  80         return dht_hash_compute_internal (type,
>  rsync_friendly_name, hash_p);
>  81 }
>
> The name comes from dht_subvol_get_hashed (a few levels up), thus.
>
>  380         subvol = dht_layout_search (this, layout, loc->name);
>
> AFAIK loc->name is just the last part of the name, and there's no
> provision anywhere in this path for non-textual input like a parent
> hash.  It would probably be a good idea for us to do something like
> that, but currently we don't.
>
>

The parent directory's textual path is not part of the hash computation,
but it causes a different hash-range map in the inode layout and
effectively a different server is picked up for the same basename in
different directories.

Avati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120417/2bc969a1/attachment-0003.html>