We assume in what follows that the environment variable
NASDROOT is set to point at the root directory of the
NASD software tree, i.e. an incantation like
foo/bar/bletch under the NASD tree.
There are five steps to starting up the NASD NFS filemanager:
rhoda.pcrpart, i.e.:
% $NASDROOT/tests/pcrpart rhoda 1 250000 0 password
would create partition number 1 with 250000 block on rhoda
with minimum required security level zero (no security) and the password "password".
% $NASDROOT/nfs/utils/nasd_nfs_format rhoda 1 password
. The second argument to nasd_nfs_format is the
partition number, and the third is the password.nasd_nfs_mounts file in
$NASDROOT/nfs/server with a line like this for each
NFS partition the filemanager will manage:
/pathname rhoda 1
Each line has a pathname, server and partition number for
each mountpoint the filemanager will export. There is an example
nasd_nfs_mounts file distributed under
$NASDROOT/nfs/etc in the release.$NASDROOT/nfs/server/nfs_server on some machine.
It can be run on the same machine running the NASD drive, but it
doesn't have to.To get at the files stored in NASD-NFS, you have to start the NASD NFS client on the machine from which you wish to access them, which is described in the section on running the NASD-NFS client.
There is a simple fsck-like utility for NASD NFS called
nasd_nfs_fsck distributed with NASD. It has the
following syntax:
| Option | Description |
|---|---|
| -v | Verbose output. |
| -D | Debugging output; implcitly turns on -v |
| -a | Automatically tries to fix any problems. |
| -n | Does not attempt to fix any problem, simply prints diagnostics. |
nasd_nfs_fsck is not terribly full-featured or complete,
but can be useful if you suspect that something has gone awry.
Running programs in tests/
| Running NASD-NFS clients | NASD Programmer's Documentation |