[OpenAFS] Strange access problems on one client
Derrick Brashear
shadow@gmail.com
Thu, 11 Oct 2007 23:20:35 -0400
------=_Part_10273_15211296.1192159235287
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On 10/11/07, Jeffrey Altman <jaltman@columbia.edu> wrote:
>
> Marc Dionne wrote:
> > Now I'm curious as to why the specific value returned by DirHash even
> > matters. Even with the gcc bug it would be consistent for a given
> > string on the same client. Does this value have to match what's
> > computed for the same string on the file server side?
>
> The hash is used to look up the name in the AFS3 directory hash table
> that is received by the client from the file server.
>
> > (looks like
> > DirHash is also used in fileserver) If so, it looks like the original
> > code could produce different values with different size ints on the
> > server and client.
>
> Good thing we are lucky that 'int' is 32-bits on all of the platforms we
> care about. I agree this should be afs_int32.
the entire dir package is bad about specifying int, long or afs_int32;
making stylistic changes now is probably not the best idea.
------=_Part_10273_15211296.1192159235287
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br><div><span class="gmail_quote">On 10/11/07, <b class="gmail_sendername">Jeffrey Altman</b> <<a href="mailto:jaltman@columbia.edu">jaltman@columbia.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Marc Dionne wrote:<br>> Now I'm curious as to why the specific value returned by DirHash even<br>> matters. Even with the gcc bug it would be consistent for a given<br>> string on the same client. Does this value have to match what's
<br>> computed for the same string on the file server side?<br><br>The hash is used to look up the name in the AFS3 directory hash table<br>that is received by the client from the file server.<br><br>> (looks like<br>
> DirHash is also used in fileserver) If so, it looks like the original<br>> code could produce different values with different size ints on the<br>> server and client.<br><br>Good thing we are lucky that 'int' is 32-bits on all of the platforms we
<br>care about. I agree this should be afs_int32.</blockquote><div><br>the entire dir package is bad about specifying int, long or afs_int32; making stylistic changes now is probably not the best idea. <br></div><br></div>
<br>
------=_Part_10273_15211296.1192159235287--