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

From: Mike Eisler <[email-masked]>
Date: Tue, 6 Feb 2001 09:25:31 -0800 (PST)

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

Which was why I suggested that this be prototyped as a prerequisite to adding
it to the protocol.
      
>         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).

This is a general claim unsupported by specifics. On the flip side, here
are some counter examples:
	- NFSv4 attempts to get byte range locking right (although, with
		the varied interpretations of stateids, sequence numbers,
		and lock owners, I'm unconvinced we have it right). Byte
		range locking is silly, but users want it. 
		
	- NFSv4 supports mandatory locking, which is sillier than
		byte range locking.
		
	- Volatile handles were driven by the fact that some servers,
		such as Linux, do not generate truly persistent file handles. 
		Linux is a grass roots user phenomenom. 
		
We can certainly continue to say no to all the above, with the excuse that
they are hard problems. We'd end up with a more elegant protocol, but
I don't know who'd use it.

In another message, Ran wrote:

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

Right because the existing NFS installed base no longer runs as much
PC/NFS.  because they are satisfied with what they get from Samba,
which uses a closed networking protocol. Is there no benefit to the
user in providing a solution based on an open specfication? 

>	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 

Perhaps there are Linux users dissatisfied with Ext2? There seems to be
a lot of energy on other local filesystems in Linux, reiserfs, xfs,
IBM's log-based filesystem, etc. No doubt what drives some of this
activity is the fun of creating new code, but I presume that
requirements drive as well. 

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

I suppose I'm guilty of ignoring a user when I say this, but I don't
see how adding support for reiserfs should make you less happy.	If
you don't deploy reiserfs in your shop, you won't notice it. If you
do, you'll notice NFSv4 works somewhat better over reiserfs than
NFSv[23] do.

		-mre

---

From: Eric Werme USG <[email-masked]>
Date: Thu, 8 Feb 2001 15:55:50 -0500 (EST)

Xuan Baldauf wrote:

> And now
>I ask again: Which application do use seekdir (except to the start of the
>directory, which is no problem), and why? And then: Which application do
>not work with the BSD-implementation of that scheme? (Only those
>applications have to be changed or only for those applications, cookie
>emulation on the kernel side is necessary.)
>
>Maybe someone can point me to applications needing seekdir|telldir.

Of the non-graphics commands supported by the Unix group at Compaq,
The only programs that call seekdir are:

bin/ltf/putfile.c     putfile  1539 seekdir(dirfile, p);
sbin/catman/catman.c  hardlink 1010 seekdir(mdir, saveptr);

Apparently ltf is a tar-like program that reads and writes ANSI labeled
magtapes.  (Do people use ANSI labeled tapes outside of the 1/2" tape
arena?)

catman is a program that preconverts man pages from nroff to text to
speed up the man command.

I don't know about other backup programs that are outside our domain
like networker or any of the CDE et al GUI apps.

I suppose another resolution to all this is to simply say reiserfs
doesn't support telldir and seekdir, either locally or over NFS.
Except for Posix and Cthon test suite users, it could be years before
anyone noticed.

	-Ric Werme

---

From: Eric Werme USG <[email-masked]>
Date: Thu, 8 Feb 2001 16:07:06 -0500 (EST)

> Except for Posix and Cthon test suite users, it could be years before

Completely forgetting the little matter of NFS clients on all but reading
the the "start" of the directory....

Too many distractions today!

	-Ric

---

From: Eric Werme USG <[email-masked]>
Date: Thu, 8 Feb 2001 15:55:50 -0500 (EST)

-Ric Werme

---

From: Eric Werme USG <[email-masked]>
Date: Thu, 8 Feb 2001 16:07:06 -0500 (EST)

-Ric

---

From: Peter Staubach <[email-masked]>
Date: Thu, 8 Feb 2001 15:32:44 -0700 (MST)

> Except for Posix and Cthon test suite users, it could be years before

In Solaris, rewinddir(3C) is implemented using seekdir(3C).  I expect
that there are a few users of rewinddir(), but I didn't really look.

		ps

---

From: Peter Staubach <[email-masked]>
Date: Thu, 8 Feb 2001 15:32:44 -0700 (MST)

ps

---

From: Mike Eisler <[email-masked]>
Date: Thu, 8 Feb 2001 14:56:18 -0800 (PST)

> that there are a few users of rewinddir(), but I didn't really look.

rewinddir does a seekdir to cookie 0, the start of the directory.
So reiserfs shouldn't break rewinddir.

BTW, the Solaris 8 seekdir() man page says:

     If the value of loc was not obtained from an earlier call to
     telldir() or if a call to rewinddir(3C) occurred between the
     call to telldir () and the call to seekdir(), the results of
     subsequent calls to readdir() are unspecified.
     
The Redhat 6.2 man page has equivalent language.
     
Assuming applications obey the above specification, then
this has the potential of making Trond's dictionary much more feasible.
Change the telldir library routine to invoke a private system call to
add a dictionary entry for the mapping of the integer cookie to
real cookie. Dictionary then tends to be much smaller.

	-mre

---

From: Mike Eisler <[email-masked]>
Date: Thu, 8 Feb 2001 14:56:18 -0800 (PST)

-mre