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

From: Mike Eisler <[email-masked]>
Date: Mon, 5 Feb 2001 14:35:47 -0800 (PST)

> As for changing the cookie definition, I have to leave it to those who have
> been more active than me.  Okay guys, the sun is up in California.  If you
> have electricity, do you have any comments?

I don't like the notion of rendering cookies that actually contain
variable length file names. The directory listing already contains file
names, and it seems obnoxious to render them again per entry, thereby
doubling the output of READDIR results. 

I gather that reiserfs must produce integer cookies for getdents()
system call to work, but that the cookies are guaranteed to work only
as long as the file is opened. If so, and had NFSv4 taken the
step of supporting OPENDIR, then cookies, like file handles, could have
had an volatile attribute. However, that's a big step that the working
group had earlier decided to defer for a future
version.

What I'm thinking of is that instead of OPENDIR, or variable length
cookies, define special integer cookie value that indicates that the name
is really the cookie. Then change the READDIR arguments from 

struct READDIR4args {
        /* CURRENT_FH: directory */
        nfs_cookie4     cookie;
        verifier4       cookieverf;
        count4          dircount;
        count4          maxcount;
        bitmap4         attr_request;
};

to:

const NFS4_NAMES_ARE_COOKIES 0xffffffffffffffff; /* 2^64 -1 */

union cookie_switch4 switch (nfs_cookie4 cookie) {
 case NFS4_NAMES_ARE_COOKIES:
         component4     name;
 default:
         void;
};

struct READDIR4args {
        /* CURRENT_FH: directory */
        verifier4       cookieverf;
        count4          dircount;
        count4          maxcount;
        cookieswitch4   locator;
        bitmap4         attr_request;
};

So if a directory entry result has the value of NFS4_NAMES_ARE_COOKIES,
then a subsequent READDIR to get the next block of entries simply takes
the name. A READDIR of a reiserfs directory would have cookies all set
to NFS4_NAMES_ARE_COOKIES. Note that the name used as a cookie does not
seek to the entry with the name, but instead the next entry after that
with that name.

Assuming this makes sense, I'd like to see someone prototype this
before making this change in next nfsv4 RFC.  The CITI folks have an
NFSv4 server for Linux (right?), so this shouldn't require much
effort.

	-mre

---

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

I don't really care whether cookies are made variable length or there is instead
a way to flag using names as cookies as suggested below.

I leave this to you guys to decide, I just want to not have to find directory
position by something other than the filename.  I suggest you make it simple
though so that it is likely to happen.:-)

Hans

> doubling the output of READDIR results.

It is a cookie per readdir, and readdir returns more than one filename in nfs,
yes?

> system call to work, but that the cookies are guaranteed to work only

There is a big difference between returning a unique object id, and offering to
find a file by it should it be cited.  We find things by keys, which we would
like to have be variable length.  

> group had earlier decided to defer for a future

No, no, finding locations in directories by some byte offset is just wrong and
ugly....
We use a balanced tree.  There is no natural byte offset in our datastructure. 
It is not a file.....