Olaf Kirch wrote:
>
> 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.
Reiserfs keys are guaranteed to be unique, else everything would collapse in our
algorithms, so we are ok here.
>
> 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.
64 bits are enough for now, but not for later.
> 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
> pleases.
Cool.
>
> 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.
We need to change the key not after rename but after repack.
>
> 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).
You got me 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.
Are you sure of this point?
>
> 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.
Maybe we can do v3 in 2.4 and v4 in 2.6 when there will be a repacker.
>
> Just my 2 cents
> Olaf
> --
> Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
> okir@caldera.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
> +-------------------- Why Not?! -----------------------
> UNIX, n.: Spanish manufacturer of fire extinguishers.
-- You can get ReiserFS at http://devlinux.org/namesys, and customizations and industrial grade support at reiser@idiom.com.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:19 EST