NFS client
The SPIN NFS client is capable of both reading and writing files from
arbitrary NFS servers. Unfortunately, we've been able to crash
Transarc's AFS/NFS translator with 256byte directory reads.
Failings of the current NFS client
The current client doesn't support everything one might find in a
typical NFS client. Some of the missing features are:
- Making directories
- Making symlinks
- Deleting files
- User and group IDs
- A read and write cache, specifically one which would be primarily
a buffer that does read-ahead and write-behind, as using larger blocks
and thus fewer transactions is a big win with NFS
- Asynchronous RPC requests
Some are these are missing because they are minor efficiency
improvements, others because SPIN isn't UNIX and doesn't know about
UIDs and GIDs. The first three are missing because the SPIN file
system interface doesn't know about them. The filesystem cache should
probably be implemented as a special cacheable filesystem ontop of
NFS. The async RPC support needs to be managed by the RPC support
package. In particular, the RPCSunUdp.SendCall procedure needs to be
redesigned, as it was intended solely to be used synchronously.
Current support features
- Opening files
- Creating files
- Reading from files
- Writing to files
- Opening directories
- Reading directories
- Stating files
- Dereferencing symlinks
- A directory & symlink handle cache
- Large block sizes
- No extra copying of data read/written in the NFS code
In order to add creation of files it was necessary to extend the SPIN
file-system interface slightly. The Open command has a parameter
called mode, which in its UNIX counterpart is used to specify flags
such as O_CREAT or O_APPEND. All the current file-systems in spin
were read-only, and ignored the mode bits. I added an O_CREATE (with
an E) flag, which causes Open to create the file if it doesn't already
exist.
The extra copy was avoided by modifying the RPC stubs generated by the ONCRPC
package. There is still some extra copying going on in there, but it's much
deeper down inside the RPC and socket code, which is currently out of my
reach.
Current problems
There are a few bugs or possible problems with the client. One is
from the directory handle cache. If a symlink points to a directory
it will cache the symlink to directory handle relation, and avoid
re-looking up the symlink, and avoid re-reading the data in the
symlink. This is good in some respects, as is reduces the number of
NFS calls that are needed to lookup the symlink component of the path
of a file beginning opened to zero. It is bad because if the symlink
ever changes the client will never re-read it. A good solution to
this might be a 30 second time-out for cached symlinks.