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
pleases.
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
--
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.
-
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:18 EST