>>>>> " " == Jeff Epler <jepler@inetnebr.com> 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
standard.
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.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:21 EST