public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Linux Kernel List <linux-kernel@vger.kernel.org>,
	Ext2 devel <ext2-devel@lists.sourceforge.net>
Subject: Still getting some NFS htree strangeness
Date: 08 Mar 2003 23:14:05 -0800	[thread overview]
Message-ID: <1047194045.8991.71.camel@ixodes.goop.org> (raw)
In-Reply-To: <E18re9F-00086y-00@think.thunk.org>

On Sat, 2003-03-08 at 05:13, Theodore Ts'o wrote:
> I've backported all of the bugfixes to the 2.5 dxdir/htree patches to
> 2.4, and have created a new set of patches for Linux 2.4.21rc5.  At this
> point it *looks* like we've fixed all of the htree bugs that people have
> reported, including the brelse bug, the memory leak bugs, and the NFS
> compatibility problems.

I'm still getting odd results from programs doing readdir over NFS.  I
haven't really nailed down what's happening yet, but I'm getting readdir
failing with EOVERFLOW.  Strace doesn't show any syscalls failing, and
an inspection of the glibc source of readdir() shows that it can return
EOVERFLOW, but I don't really understand the code yet.  It may be that
it assumes that the getdents "offset" is really a file offset rather
than a random number.  

I'm inclined to suspect that it is a glibc bug, but I'm not willing to
say so until I've worked out what's really going on.  Also, even if it
were, it would be worth working around if possible (otherwise htree+nfs
is still effectively useless).

I'll see if I can get something more concrete showing what's going on.

	J


      reply	other threads:[~2003-03-09  7:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-08 13:13 Updated 2.4 htree patches available for 2.4.21rc5 Theodore Ts'o
2003-03-09  7:14 ` Jeremy Fitzhardinge [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=1047194045.8991.71.camel@ixodes.goop.org \
    --to=jeremy@goop.org \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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