NASD/NFS Prototype

In a NASD-adapted filesystem, files and directories are stored in NASD objects. The mapping of files and directories to objects depends upon the filesystem. For our NFS port, we use a simple approach: each file and each directory occupies exactly one NASD object, and offsets in files are the same as offsets in objects. This allows common file attributes (e.g. file length and last modify time) to correspond directly to NASD-maintained object attributes. The remainder of the file attributes (e.g. owner and mode bits) are stored in the objectM-^Rs uninterpreted attributes. Because the filesystem makes policy decisions based on these file attributes, the client may not directly modify object metadata; commands that may impact policy decisions such as quota or access rights must go through the file manager.

The combination of a stateless server, weak cache consistency, and few filesystem management mechanisms make porting NFS to a NASD environment straightforward. Data-moving operations (read, write) and attribute reads (getattr) are directed to the NASD drive while all other requests are handled by the file manager. Capabilities are piggybacked on the file managerM-^Rs response to lookup operations. File attributes are either computed from NASD object attributes (e.g. modify times and object size) or stored in the uninterpreted filesystem-specific attribute (e.g. mode and uid/gid).

The client was minimally modified by changing the RPC requess while the file manager was built from the ground up. All the RPCs were changed to use DCE which is required for our NASD prototype. The file manager caches attributes and directories in order to avoid redudant communication with the drives.

NASD/NFS and NFSv3 have similar performance, with NASD/NFS running 10% slower than NFSv3 for a couple of reasons. First, DCE RPC's performance is not as optimized as ONC RPC which is seen by NFSv3 handling twice as many null RPCs per second as NFSv3. Additionally. our NFS file manager is implemented at user level which requires extra kernel traps. Finally, some NASD/NFS operations simply spend more time on the wire requiring message to both the file manager and the drive.

We also measured the scalability of NASD/NFS versus NFSv3 with four drives being accessed by four clients. With NFSv3, we were able to achieve 10.5 MB/s of raw bandwidth before we satured the file server CPU. With NASD/NFS, we achieved 12.5 MB/s with only 1.5% file manager CPU utilization. These demonstrate the validity of the NASD scalability claims.