Subject: Formal Request for cookies to be made variable length

From: Hans Reiser <[email-masked]>
Date: Mon, 05 Feb 2001 23:32:49 +0300

I hereby make it.

It seems that making these requests formally is considered more effective.

Lack of variable length cookies makes them into thinly disguised hardcoded byte
offsets into directories.  This prevents the use of modern algorithms in
filesystem design.  For instance, stem compression of filenames is made
infeasible in reiserfs by the need to index filenames by their hash so that the
key for the filename can fit into a 32 bit cookie.  This is because stem
compression depends on lexicographic ordering for compression efficiency, which
hash ordering is inimical to.  We would like to do stem compression in ReiserFS
in the Linux 2.6 time frame, and NFS v4 is the primary impediment to this.

Hans

---

From: Neil Brown <[email-masked]>
Date: Tue, 6 Feb 2001 09:51:06 +1100 (EST)

On Monday February 5, [email-masked] wrote:
> hash ordering is inimical to.

I thought it would be worth looking at the consequences/implications
of this idea, particularly in the context of reiserfs which "wants" to
store file (base)names in the cookie.

If you look at "struct entry4" in rfc3010, you see that one
nfs_cookie4 is returned for every name.

This would leave the possibly bizarre situation that every name is
sent to the client twice!

Possibly if we were to allow variable length cookies in a subsequent
minor version we should consider only sending one cookie per readdir
response. 

>                                 We would like to do stem compression in ReiserFS

I would suspect that NFSv2 and NFSv3 are strong impediments too.
The fact that NFSv2 is still in wide spread use suggests that we won't be
loosing NFSv3 any time soon either.

But I would have thought that telldir/seekdir would have been a
bigger impediment.  They require that a location in a directory be an
"off_t".  I can imagine convincing libc that an off_t were 64bits, but
convincing it that an off_t were of no fixed length seems a bit far
fetched.

We already have enough trouble with client NFSv3 implementations
coping with 64bit readdir cookies.  How well client implementations
would cope with variable length cooikes I don't know.

</court-jester-mode>
I think that the only complete solution to this problem would be to
simply disallow "seekdir".  Few programs actually use it, and those
that do can probalby be re-written fairly easily.  The main use that I
have seen is to recursively walk a directory tree, but not have to
keep every ancestor of the "current" directory open.  Now that almost
everybody has more than 20 file descriptors (often atleast 1024),
keeping everything open is not so much of a barrier.

The NFS server would then need to keep some state about each open
directory being a pointer to the "next" entry, but NFSv4 is good at
keeping state for open files.

There is a precedent for NFS mandating changes to the filesystem
interface.  Ever since NFSv2, no-one interested in portable code
trusts O_CREAT|O_EXCL any more.  They all rewrote their programs to
achieve the same result in a different way.  If we deliberately (but
quietly) break seekdir, but provide clients that provide a compatible
but imperfect emulation (rewind and count filenames) then people will
stop using seekdir like they stopped using O_EXCL.

</court-jester-mode>

> Hans

NeilBrown

---

From: Hans Reiser <[email-masked]>
Date: Tue, 06 Feb 2001 01:32:15 +0300

> nfs_cookie4 is returned for every name.

I stand corrected.  The concern is valid.  Using the cookie as a flag is
reasonable.
I don't know why there is a cookie per filename so I can't comment on whether
there could be just one cookie per readdir.

> stop using seekdir like they stopped using O_EXCL.

I must tell you that ReiserFS is not a friend of seekdir() either.  Breaking
seekdir() is in all seriousness not such a bad thing to do.

Hans

---

From: Eric Werme USG <[email-masked]>
Date: Mon, 05 Feb 2001 20:30:00 -0500

I don't know why there is a cookie per filename so I can't comment on
   whether there could be just one cookie per readdir.

The problem has been that directory formats can be so different between
the client's user API and NFS's readdir that it's hard for the client to
request exactly the right request that will exactly fill the buffer
available for getdirentries.  So some implementations make a decent
guess and if they get back a little too much, just discard the excess.
With a cookie per dirent, it's easy to save the right cookie.  With
one per readdir, clients would have to buffer the extra data and return
that for the next getdirentries() call.

You can't readily hang the buffer off the vnode, as there may be multiple
readers of the directory, so you'd have to buffer several or hang it of
the struct file structure.  Or something like that.

	-Ric Werme