[lkml]   [2002]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: BUG REPORT: kernel nfs between 2.4.19-pre2 (server) and 2.2.21-pre3 (client)
Trond Myklebust wrote:
> Rigging the client in order to cope with *all* the consequences in
> terms of unfsd races is an exercise in futility - it cannot be
> done.
> The solution is not to keep flogging the dead horse that is unfsd. It
> is to put the effort into fixing knfsd so that it can cope with all
> those cases where people are using unfsd today.

Agreed in general. That's the way to go.

* * *

> Sure, but it is a consequence of a badly broken server that violates
> the NFS specs concerning file handles.

I have technical concern here. Is the server violating specs?

Please correct me, if I am wrong. I've read through rfc1094, rfc1813,
XNFS specification of Opengroup and NFS v3 specification by Sun, I
cannot find the description of... :
reuse of file handle in server side is wrong.

File handle must be unique. But I think that it may be reused (for
different type). Client side cache should handle this case, IMO.

There is an explanation for the file handle in NFS v3 specification by Sun
Servers should try to maintain a one-to-one correspondence between
file handles and files, but this is not required. Clients should use
file handle comparisons only to improve performance, not for correct

Current client implementation of Linux uses a file handle for
correctness, in the scenario I've described.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:25    [W:0.094 / U:6.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site