On Tue, Apr 17, 2012 at 8:20 AM, Jeff Darcy <[email protected]> wrote:
> On Tue, 17 Apr 2012 11:14:21 -0400 (EDT) > Kaleb Keithley <[email protected]> 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
_______________________________________________ Gluster-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/gluster-devel
