[lkml]   [2000]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee
>>>>> " " == Jeff Epler <> writes:

> On Wed, Sep 13, 2000 at 02:53:02PM +0200, Trond Myklebust
> wrote:
>> No. Things fall in and out of the inode cache all the
>> time. That's a vicious circle that's going to lead to a lot of
>> unnecessary traffic.

> The traffic is not "unnecessary" if it's needed to work with
> today's NFS servers and get correct results. We need an
> absolute guarantee in nfs_lock() that we won't read stale data,
> we need it when working with non-linux NFS servers, and we need
> it today.

That's the joy of free software: you're free to patch in any hack you
and your clients need.

The goal of the official 2.4.x kernel however should IMO be to follow
the specs which is what we do now.
If current Linux servers are broken w.r.t. NFS specs then a hack to
the Linux client won't fix them, and they will continue to break on
non-Linux clients.
NFS has a mechanism for solving this problem, and it is a mechanism
that most (if not all) non-linux servers implement. That is what we
need to implement too if we're serious about conforming to the

I'm quite willing to help fix the server (something I indeed think
should be done), but to further obscure the code in the client with
yet another bandaid for broken servers is not something I personally
will help do.

Perhaps Linus will indeed accept such a patch, in which case you (or
anybody else) are quite free to construct it and pass it on to him.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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