From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
Ext2 devel <ext2-devel@lists.sourceforge.net>,
NFS maillist <nfs@lists.sourceforge.net>,
Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: [Ext2-devel] Re: [NFS] htree+NFS (NFS client bug?)
Date: 27 Nov 2002 23:44:01 +0100 [thread overview]
Message-ID: <shslm3e4or2.fsf@charged.uio.no> (raw)
In-Reply-To: <20021127205554.J2948@redhat.com>
>>>>> " " == Stephen C Tweedie <sct@redhat.com> writes:
>> If glibc issued a new readdir request (which is what I suspect
>> has happened here), the NFS client has no idea what the
>> previous reply was
> Well, glibc will *always* issue another readdir, because the
> only way we can ever tell glibc that we're at EOF on the
> directory is when we eventually return 0 from getdents. The
> question about client behaviour is, if we've already been told
> that the stream is at EOF, should the client simply discard
> that info and keep reading regardless, or should it cache the
> EOF status?
We could possibly cache the EOF status by overloading some other field
in the struct file. f_version comes to mind as a useful candidate,
since it automatically gets reset by llseek.
Cheers,
Trond
next prev parent reply other threads:[~2002-11-27 22:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-26 23:44 htree+NFS (NFS client bug?) Jeremy Fitzhardinge
2002-11-27 3:26 ` [NFS] " Trond Myklebust
2002-11-27 2:59 ` [Ext2-devel] " chrisl
2002-11-27 8:58 ` Jeremy Fitzhardinge
2002-11-27 15:00 ` Stephen C. Tweedie
2002-11-27 15:00 ` [Ext2-devel] " Stephen C. Tweedie
2002-11-27 20:25 ` Trond Myklebust
2002-11-27 20:55 ` Stephen C. Tweedie
2002-11-27 20:55 ` [Ext2-devel] " Stephen C. Tweedie
2002-11-27 22:44 ` Trond Myklebust [this message]
2002-11-28 16:41 ` Stephen C. Tweedie
2002-11-28 16:41 ` [Ext2-devel] " Stephen C. Tweedie
2002-11-28 16:58 ` Trond Myklebust
2002-11-28 16:58 ` [Ext2-devel] " Trond Myklebust
2002-11-28 17:09 ` Stephen C. Tweedie
2002-11-28 17:09 ` [Ext2-devel] " Stephen C. Tweedie
2002-11-28 17:57 ` Trond Myklebust
2002-11-28 17:57 ` [Ext2-devel] " Trond Myklebust
2002-11-28 16:44 ` Stephen C. Tweedie
2002-11-28 16:44 ` [Ext2-devel] " Stephen C. Tweedie
2002-11-28 17:13 ` Stephen C. Tweedie
2002-11-28 17:13 ` [Ext2-devel] " Stephen C. Tweedie
2002-11-28 17:44 ` Trond Myklebust
2002-11-28 17:44 ` [Ext2-devel] " Trond Myklebust
2002-11-28 20:00 ` Jeremy Fitzhardinge
2002-11-28 2:07 ` Jeremy Fitzhardinge
2002-11-28 2:46 ` Trond Myklebust
2002-11-27 13:33 ` Theodore Ts'o
2002-11-27 20:42 ` Trond Myklebust
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=shslm3e4or2.fsf@charged.uio.no \
--to=trond.myklebust@fys.uio.no \
--cc=ext2-devel@lists.sourceforge.net \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nfs@lists.sourceforge.net \
--cc=sct@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.