Re: [RFC] Improved distribution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tue, Apr 17, 2012 at 8:20 AM, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote:
On Tue, 17 Apr 2012 11:14:21 -0400 (EDT)
Kaleb Keithley <kkeithle@xxxxxxxxxx> 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
 

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux