Re: (reiserfs) reiserfs and knfsd and NFSv4 and volatile file handles

From: Olaf Kirch (
Date: Thu Mar 16 2000 - 06:31:00 EST

I've taken the NFSv4 WG off the Cc, because I think this is moving quite
a bit away from their interests.

Here's a bunch of observations that may help (please take with
a grain of salt; it's been a while since I did active NFS coding):

 1. There are various standards out there that very much like
        "inode numbers" to be unique. Tools like tar will barf badly
        if they're not. Whether they're supposed to be stable is a
        different issue. Whether they are supposed to be just
        32 bit is also an entirely different issue.

 2. When talking about NFS, "inode numbers" appear in two
        different roles. First as the "fileid" attribute to
        a file system object; this value is 32bit in v2 and
        64bit in v3. Second, "inode numbers" are currently
        used heavily in the file handles created by knfsd.

 3. Neil Brown is working on patches that allow variant
        file handle layouts per filesystem. This will allow
        reiserfs to use up the 32 bytes (64 in v3) as it

        There are some boundary conditions like checking of export
        points, and a certain portion of code (like connecting
        dnodes) may have to be copied; but those are probably just
        details that shouldn't affect the design of reiserfs.

 4. The file handles used by the old user space nfsd have
        never been invariant under moving to a different directory.
        However I don't think anybody ever noticed except people doing
        conformance testing or benchmarking.

        So there is some precedent if the reiserfs designers choose to
        take an approach that ensures that the object id remains constant
        as long as an object does not move to a different directory,
        but nothing more.

 5. It may be worthwhile to put the entire key (including offset)
        into an NFS file handle because ninety-odd percent of
        all file handles are extremely short-lived (whereas the
        packer is supposed to run once a day if I got Hans right).
        So the worst case would be that _some_ file handles arrive
        that have the right directory and object ID but the wrong
        offset. This error can probably be detected, I would assume.
        This could be corrected by performing a directory search and
        taking the performance hit; optionally, there could be a
        small to medium sized cache that contains fix-up information
        for these semi-stale file handles.

 6. It may not hurt much if reiserfs is aiming just at NFSv3
        and ignores NFSv2 completely. Exporting a modern file
        system over 1980s technology is quite a bad match.
Just my 2 cents

Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play    |    / | \   sol.dhoop.naytheet.ah
                   +-------------------- Why Not?! -----------------------
         UNIX, n.: Spanish manufacturer of fire extinguishers.            

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:18 EST