negative NFS cookies: bad C library or bad kernel?

From: Trond Myklebust (trond.myklebust@fys.uio.no)
Date: Sun Dec 03 2000 - 08:30:37 EST


>>>>> " " == Kevin Buhr <buhr@stat.wisc.edu> writes:

> However, who's to blame here? It can't be CFS---any four-byte
> cookie should be valid, right?

> Is the kernel NFS client code to blame? If it's going to be
> using cookies as offsets, shouldn't we have an nfs_lseek that
> special-cases directory lseeks (at least those using SEEK_SET)
> to take negative offsets, so utilities and libraries don't need
> to be bigfile-aware just to read directories? And what in the
> world can we do about bogus code like the:

The problem here is that in NFS we have to match cookies in lieu of
using true directory 'offsets'. I did try to work around this by using
offsets into the page cache and the likes, however this sort of scheme
is almost impossible to implement sanely because an offset into the
page cache changes all the time. This was why I returned to Olaf's
scheme in which we use the cookie as the return value for lseek &
friends.

The problem then arises that lseek tries to cram both a returned
offset and an error value into the return values. When NFS returns an
opaque type, this causes a problem; one that won't be fixed by adding
an nfs_lseek. Furthermore, lseek is 32-bits: for NFSv3 and higher, the
cookie is 64-bits...

I know of no scheme that can fix all problems with lseek.
For example concerning SEEK_CUR: forget about it. NFS is not POSIX and
never will be. You simply cannot give meaningful semantics to SEEK_CUR
as long as the client knows nothing about the organization of dirents
on the server.

We can return offsets that are based on the internal caching of
dirents, but the problem then is that you need to find some permanent
'index' that doesn't change when we invalidate the cache and read it
in anew. Making stuff like 'rm -rf *' work (when the directory size &
organization keeps changing) is quite a challenge...
One possibility would be to make a pointer into a table of cookies be
our 'offset'. That could work if we can ensure that cookies can't move
around...

Cheers,
  Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Dec 07 2000 - 21:00:09 EST