Subject: RE: [reiserfs-list] Directory cookie issues

From: "Corbett, Peter" <[email-masked]>
Date: Tue, 6 Feb 2001 08:14:42 -0800

Just to throw in two more cents:
Doesn't the combination of the 8 byte cookie, plus the 8 byte opaque
verifier, both of which will come back from the client, give you enough to
store your 16 byte key and renavigate the b-tree (without changing the
protocol)?

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Tuesday, February 06, 2001 9:51 AM
To: Hans Reiser
Cc: [email-masked]
Subject: Re: [reiserfs-list] Directory cookie issues

At 08:32 06/02/01, Hans Reiser wrote:
>The problem with your position is that the cookies changes 
>proposed will make NFS more general and less encumbering 
>to many future filesystems.

Hans,

        That is your claim.  However it is not at all clear 
either whether that claim is correct or that such a change 
won't adversely impact interoperability of currently deployed 
NFS systems.  
        
        More general is not necessarily better or more 
interoperable or lower operational complexity.

        Currently deployed NFS systems are generally a misture
of NFSv2 and NFSv3.  The NFSv2 systems aren't going away very
quickly.  Adding current NFSv4 is already complicating the mix
operationally.  Making the additional change will likely 
complicate things even further.

        I don't believe the NFS WG is giving sufficient attention
and weight to operational/user concerns.  This is mostly due to
limited user involvement.  Limited user involvement is at least
partly due to certain WG participants actively tuning out the
user comments (though other WG participants are trying to listen).

Ran
[email-masked]

---

From: Hans Reiser <[email-masked]>
Date: Tue, 06 Feb 2001 19:21:02 +0300

NFS v4 is just fine for our current code, which we have grudgingly distorted to
fit it.  We don't want to use our current hashing scheme.  It is inferior,
because stem compression cannot be done without lexicographic ordering, and the
hash has all kinds of complexity and side effects, and lexicographic ordering is
typically an order of magnitude in performance superior for the sorts of apps
that tend to insert a few million entries into a directory.

If we don't use our current hashing scheme, then we need to describe position by
the filename, which has the side effect of requiring that keys and cookies
support variable lengths.

Hans