mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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: Thu, 28 Nov 2002 18:44:15 +0100	[thread overview]
Message-ID: <15846.21999.949270.354293@charged.uio.no> (raw)
In-Reply-To: <20021128171324.G2362@redhat.com>

>>>>> " " == Stephen C Tweedie <sct@redhat.com> writes:

     > We're only using 31-bit hashes right now.  Trond, how will
     > other NFS clients react if we return an NFS cookie 32-bits
     > wide?  We could easily use something like 0x80000000 as an
     > f_pos to represent EOF in the Linux side of things, but will
     > that cookie work if passed over the wire on NFSv2?

For all other NFS clients that I know of, this is perfectly
acceptable. As far as the Linux kernel goes, it is quite OK, but when
you get to userland, glibc-2.2 and above will insist that this is an
illegal value (they like to sign extend 32-bit values). Causes no end
of trouble, since XFS tends to use '0xffffffff' as the EOF cookie.

I have a patch that hacks the values of such cookies so that glibc
will accept them. That hack will never go in to the official kernel,
so it would be nice if ext2/ext3 could avoid the need for it.

     > The alternative is to hack in a special case so that (for
     > example) we consider a major htree hash of 0x7fffffff to map to
     > an f_pos of 0x7ffffffe and just consider that a possible
     > collision, so that 0x7fffffff is a unique EOF for the htree
     > tree walker.

That would be fine.

Cheers,
  Trond

  reply	other threads:[~2002-11-28 17:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-26 23:44 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     ` [Ext2-devel] " Stephen C. Tweedie
2002-11-27 20:25       ` Trond Myklebust
2002-11-27 20:55         ` Stephen C. Tweedie
2002-11-27 22:44           ` Trond Myklebust
2002-11-28 16:41             ` Stephen C. Tweedie
2002-11-28 16:58               ` Trond Myklebust
2002-11-28 17:09                 ` Stephen C. Tweedie
2002-11-28 17:57                   ` Trond Myklebust
2002-11-28 16:44           ` Stephen C. Tweedie
2002-11-28 17:13             ` Stephen C. Tweedie
2002-11-28 17:44               ` Trond Myklebust [this message]
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=15846.21999.949270.354293@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®