At first, this sounds like a cool idea. However, there are two problems.
On one hand, I somehow doubt you'll find reasonable invariants for most
file systems that also fit into an NFS file handle. On the other hand,
most clients do impart special meaning on the fileid (aka inode number)
returned by the server. Most clients treat NFS as a Unixoid file system
and the fileid as inode number. If you generate identical inode numbers
for different files, you can end up with file corruption (people exporting
RAID arrays with unfsd may be faimiliar with this). If the fileid changes
while a client has the FH cached (e.g. because the file is open) weird
things happen as well.
Aside: If you start to put nfsd-related functions into individual file
systems, there's probably a number of things that would improve knfsd
if they were handled below the VFS layer.
What comes to mind first is a replacement for f_op->read() that returns
the VFS buffers themselves rather than copying file data to a buffer
supplied by nfsd. That would get us a considerable speedup on the
READ case, because that would eliminate the last memcpy in the code
path (except for the skb to ethercard copy).
Olaf
-- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax- 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/