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

From: Mike Eisler <[email-masked]>
Date: Mon, 5 Feb 2001 16:08:09 -0800 (PST)

> 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.

Of course ... for large directories it would be as impractical for
reiserfs to store all the fake cookies that have been returned, as it
would be the nfs filesystem using my suggested NFS4_NAMES_ARE_COOKIES!
So my notion of OPENDIR as the panacea is wrong.  In which case, the
kludge I've submitted may not be that bad ... it simply provides equal
degrees of brokenness as reisferfs. Though I certainly share the
opinion that seekdir() is evil.

Neil's notion of rewind and count filenames would at least allow
seekdir to work without generating an error.

	-mre

---

From: Eric Werme USG <[email-masked]>
Date: Mon, 05 Feb 2001 19:59:42 -0500

> seekdir() is in all seriousness not such a bad thing to do.
   
   Though I certainly share the opinion that seekdir() is evil.

At least there's one thing in which we're all in agreement!  :-)

While this would work okay with my example of readdir/delete/readdir,
it would fail miserably on readdir/delete/seekdir/readdir.  Somehow,
that doesn't bother me at all.  (And I wasn't the one that had to
rewrite Tru64's directory code to make the Connectathon telldir test
work!)

	-Ric Werme

---

From: Trond Myklebust <[email-masked]>
Date: 06 Feb 2001 12:20:22 +0100

>>>>> " " == Eric Werme USG <[email-masked]> writes:

     > Hans & mre commiserate:
    >> 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.

 
     >    Neil's notion of rewind and count filenames would at least
     >    allow seekdir to work without generating an error.

     > While this would work okay with my example of
     > readdir/delete/readdir, it would fail miserably on
     > readdir/delete/seekdir/readdir.  Somehow, that doesn't bother
     > me at all.  (And I wasn't the one that had to rewrite Tru64's
     > directory code to make the Connectathon telldir test work!)

I agree, but some of the userland stuff relies on this. In Linux in
particular glibc gets messed up if it can't lseek() every now and then
on a getdents call. It's a real pain and is the reason why I'm having
to modify our readdir cookie handling after 2.4.0 was released, but
people do unfortunately expect a minimum of POSIX compatibility...

Note: The same people have a tendency to whine when 'rm -rf' fails
with an ENOTEMPTY after you've counted the wrong number of filenames.

Cheers,
  Trond

---

From: Hans Reiser <[email-masked]>
Date: Tue, 06 Feb 2001 14:58:06 +0300

> rewrite Tru64's directory code to make the Connectathon telldir test

The performance would be extremely poor for 100,000 entry directories.

Hans

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 06 Feb 2001 07:36:32 -0500

I'll put on my customer/user hat about now.  As noted
earlier on, I'm NOT tremendously happy about the extra gorp 
already added to NFSv4 to accomodate certain platforms that 
are broken wrt to NFS concepts and architecture.  Those changes 
are likely to reduce my interoperability in practice, 
though they were justified as improving interoperability 
with Microsoft (which is not of concern to a large subset 
of the NFS installed base, to be honest).

	I will be even less happy if we alter/change/add
stuff to support yet another unique filesystem, given
that Linux Ext2 works OK now with NFSv4.  I have nothing 
against folks doing new filesystems or kinds of filesystems.  
I have a lot of issues with every filesystem group trying
to tweak the NFS spec to "better" support their particular
file system implementation and model.

	My blunt suggestion is that if the technical challenges
are as high as seem to be claimed, maybe the ReiserFS folks 
should consider jut NOT supporting NFS and instead roll your 
own distributed file system or try AFS or something else (SMB?).

Yours for a simpler and more reliable NFS,

Ran
[email-masked]

---

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

The problem with your position is that the cookies changes proposed will make
NFS more general and less encumbering to many future filesystems.
It is really not so bad to make a cookie of -1 mean that you use the filename as
the cookie.

Hans

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 06 Feb 2001 09:50:49 -0500

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: Eric Werme USG <[email-masked]>
Date: Tue, 06 Feb 2001 11:53:11 -0500

Well, there is the little issue that VMS uses -1 as the cookie at EOF. 
However, I think it's 2^32 - 1, not 2^64 - 1.  At any rate, I don't doubt
it's a major problem for VMS.  (BTW, before anyone notes that VMS is dead and
not worth worrying about, note that VMS business was up last year.) 

	-Ric Werme