All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: trond.myklebust@fys.uio.no
Cc: Chris Mason <mason@suse.com>, Andi Kleen <ak@suse.de>,
	Craig Soules <soules@happyplace.pdl.cmu.edu>,
	linux-kernel@vger.kernel.org
Subject: Re: NFS Client patch
Date: Fri, 20 Jul 2001 15:30:56 +0400	[thread overview]
Message-ID: <3B581670.548B3693@namesys.com> (raw)
In-Reply-To: <177360000.995464676@tiny> <shsg0btnobs.fsf@charged.uio.no> <3B5720B2.A4D97ECF@namesys.com> <15191.61681.847920.761502@charged.uio.no>

Trond Myklebust wrote:
> 
> >>>>> " " == Hans Reiser <reiser@namesys.com> writes:
> 
>      > The current code does rely on hidden knowledge of the filesytem
>      > on the server, and refuses to operate with any FS that does not
>      > describe a position in a directory as an offset or hash that
>      > fits into 32 or 64 bits.
> 
> I'm not saying that ReiserFS is wrong to question the correctness of
> this. I'm just saying that NFSv2 and v3 are fixed protocols, and that
> it's too late to do anything about them. I read Chris mail as a
> suggestion of creating yet another NQNFS, and this would IMHO be a
> mistake. Better to concentrate on NFSv4 which is meant to be
> extendible.
> 
>      > But be calm, I am not planning on fixing this myself anytime in
>      > the next year, we have an ugly and hideous hack deployed in
>      > ReiserFS that works, for now I am just saying the folks who
>      > designed NFS did a bad job and resolutely continue doing a bad
>      > job, and if someone wanted to fix it, they could fix cookies to
>      > use filenames instead of byte offsets for those filesytems able
>      > to better use filenames than byte offsets to describe a
>      > position within a directory, and for those clients and servers
>      > who are both smart enough to understand filenames instead of
>      > cookies (able to understand the cookie monster protocol).
> 
> This is something which I believe you raised in the NFSv4 group, and
> which could indeed be a candidate for an NFSv4 extension. After all,
> this is in essence a recognition of the method most NFS clients
> implement for recovering from an EBADCOOKIE error. Why was the idea
> dropped?

Lack of desire to do anything, near as I could tell.

> 
> (Note: As I said, under Linux we're currently hampered when
> considering the above alternatives by the fact that glibc requires the
> ability to lseek() on directories. This is a bug that they could
> easily fix, and it affects not only your suggestion, but also all the
> other suggestions in which one implements non-permanent cookies)

I would be quite happy if you (or anyone) could fix it, sometime in the next 3 years.  

> 
> Cheers,
>    Trond

  reply	other threads:[~2001-07-20 11:34 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.3.96L.1010709131315.16113O-200000@happyplace.pdl.cmu.edu.suse.lists.linux.kernel>
2001-07-09 18:33 ` NFS Client patch Andi Kleen
2001-07-10 13:33   ` Chris Wedgwood
2001-07-10 13:41     ` Andi Kleen
2001-07-10 16:48       ` Craig Soules
2001-07-10 17:06         ` Andi Kleen
2001-07-10 18:04           ` Chris Wedgwood
2001-07-12 20:57             ` Alan Cox
2001-07-13 11:26               ` Chris Wedgwood
2001-07-17 22:02   ` Hans Reiser
2001-07-17 22:14     ` Craig Soules
2001-07-17 22:21       ` Hans Reiser
2001-07-18 13:30         ` Daniel Phillips
2001-07-18 14:46           ` Hans Reiser
2001-07-18 14:00         ` Jan Harkes
2001-07-18 14:46           ` Hans Reiser
2001-07-19 18:24             ` Pavel Machek
2001-07-22 15:15               ` Rob Landley
2001-07-23  2:02                 ` Horst von Brand
2001-07-23  9:57                   ` Rob Landley
2001-07-18 13:57     ` Chris Mason
2001-07-19 11:35       ` Trond Myklebust
2001-07-19 18:02         ` Hans Reiser
2001-07-20  8:50           ` Trond Myklebust
2001-07-20 11:30             ` Hans Reiser [this message]
2001-07-20 14:07             ` Chris Mason
2001-07-09 17:28 Craig Soules
2001-07-09 18:59 ` Trond Myklebust
2001-07-09 19:45   ` Craig Soules
2001-07-09 19:53     ` Charles Cazabon
2001-07-09 20:05     ` Trond Myklebust
2001-07-09 22:09       ` Craig Soules
2001-07-10  8:22         ` Trond Myklebust
2001-07-10 13:38           ` Chris Wedgwood
2001-07-11  8:14             ` Trond Myklebust
2001-07-09 21:46     ` J. Richard Sladkey
2001-07-10 15:06       ` Craig Soules

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=3B581670.548B3693@namesys.com \
    --to=reiser@namesys.com \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mason@suse.com \
    --cc=soules@happyplace.pdl.cmu.edu \
    --cc=trond.myklebust@fys.uio.no \
    /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.