The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Vladimir Volovich <vvv@vsu.ru>
Cc: linux-kernel@vger.kernel.org
Subject: Re: nfs - duplicate directory entries
Date: Fri, 10 Aug 2007 17:20:02 -0400	[thread overview]
Message-ID: <1186780802.6642.78.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <873ayrgkx9.fsf@vvv.vsu.ru>

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


      reply	other threads:[~2007-08-10 21:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-10 19:21 nfs - duplicate directory entries Vladimir Volovich
2007-08-10 20:42 ` Trond Myklebust
2007-08-10 21:05   ` Vladimir Volovich
2007-08-10 21:20     ` Trond Myklebust [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1186780802.6642.78.camel@heimdal.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vvv@vsu.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox