<br><br><div class="gmail_quote">On Tue, Apr 17, 2012 at 8:20 AM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com">jdarcy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, 17 Apr 2012 11:14:21 -0400 (EDT)<br>
Kaleb Keithley <<a href="mailto:kkeithle@redhat.com">kkeithle@redhat.com</a>> wrote:<br>
<br>
> ISTR Avati and/or Vijay telling us — when we were in BLR — that the<br>
> hash of the filename is salted with the hash of the pathname up to,<br>
> but not including the filename.<br>
><br>
> Am I misremembering that? (Of course I haven't looked at the code.)<br>
<br>
</div>I just did, and if there's anything but the name included I'm missing<br>
it. Here's the DHT function that computes the hash.<br>
<br>
73 int<br>
74 dht_hash_compute (int type, const char *name, uint32_t *hash_p)<br>
75 {<br>
76 char *rsync_friendly_name = NULL;<br>
77<br>
78 MAKE_RSYNC_FRIENDLY_NAME (rsync_friendly_name, name);<br>
79<br>
80 return dht_hash_compute_internal (type,<br>
rsync_friendly_name, hash_p);<br>
81 }<br>
<br>
The name comes from dht_subvol_get_hashed (a few levels up), thus.<br>
<br>
380 subvol = dht_layout_search (this, layout, loc->name);<br>
<br>
AFAIK loc->name is just the last part of the name, and there's no<br>
provision anywhere in this path for non-textual input like a parent<br>
hash. It would probably be a good idea for us to do something like<br>
that, but currently we don't.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>Avati</div><div> </div></div>