[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1186780802.6642.78.camel@heimdal.trondhjem.org>
Date: Fri, 10 Aug 2007 17:20:02 -0400
From: Trond Myklebust <trond.myklebust@....uio.no>
To: Vladimir Volovich <vvv@....ru>
Cc: linux-kernel@...r.kernel.org
Subject: Re: nfs - duplicate directory entries
On Sat, 2007-08-11 at 01:05 +0400, Vladimir Volovich wrote:
> "TM" == Trond Myklebust writes:
>
> >> i.e. the current directory contains sub-directory 112920 twice,
> >> sub-directory 112921 twice, etc. - and the inode numbers are the
> >> same.
>
> TM> That can happen if the NFS server doesn't send unique cookies.
>
> i have 2 questions:
>
> 1) how to debug this, to confirm that this is caused by NFS server not
> sending unique cookies? (to try to report to the "vendor" of the
> NFS server)
You would have to use something like 'wireshark' or 'ethereal' to look
at the actual cookies returned by the server in reply to client READDIR
requests.
> 2) does it make sence to try to gracefully work-around this problem on
> the linux side? or would it significantly complicate things?
Assuming that it is indeed the non-unique cookie problem:
Firstly, it is my policy never to fix NFS server bugs inside the NFS
client.
Secondly, it is in any case impossible to work around this sort of thing
reliably. The cookie is used by the client in the case where you have a
large directory that requires several READDIR rpc calls. It acts in much
the same way telldir()/seekdir() does: the server supplies the cookie in
a previous READDIR call, then upon the next call to READDIR, the client
uses the cookie to tells the server to first seekdir() to the location
that was last read, and then to resume from there.
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists