As
soon as the directories representing the views are shared on the server it is
possible to map the directories as network drives on the client PC.
For instance, the view jukeman on the server jukeserver is
shared. To use it from a client, you can select Map Network Drive from
the explorer:
NFS clients, e. g., UNIX clients, can mount the standard views
<jukeman_hostname>:/views_pc
or
<jukeman_hostname>:/views_rr
of a Windows NT JUKEMAN server.
For example:
mount -o timeo=99,retrans=14 jm_hostname:/views_pc /cds
The disks can then be accessed from the directory /cds on the
client.
Both the UNIX and NT versions of iXOS-JUKEMAN support the NFS protocol. NFS
clients can mount the file system of a UNIX JUKEMAN server as they mount
any network file system, but they need to add some parameters for the
mount command. For example,
mount -o port=4027,timeo=99,retrans=14,soft <hostname>:/views_rr /cd
mounts the server's file system on the empty directory /cd of the
client. Once this is done, all disks appear as subdirectories of /cd.
The simple command ls -l /cd shows a list of all available disks.
Depending on the operating system, some versions of mount require
additional parameters, e. g.,
mount -F nfs -o port=.. or mount -f NFS,port=.... See man
mount for details.
The port=4027 option tells mount that the NFS server uses
port 4027 instead of 2049, which is used by the standard NFS daemon. This
enables the server to coexist with the standard nfsd so clients can
use both hard disks and jukeboxes on the server computer concurrently. NT does
not include a standard nfsd; consequently, the NT version uses the
standard port, and you do not need to specify the port number.
For some newer UNIX operating systems like Solaris 2.5 or 2.6, DEC UNIX 4.0 or
IRIX 6.4, the mount command should include an additional option
`vers=2'. Without this option, NFS version 3 would be used.
iXOS-JUKEMAN supports NFS protocol version 2 only, so that the client would use
version 2 anyway after negotiating with the server.
mount -o port=4027,timeo=99,retrans=14,soft,vers=2 host:/views_rr /cd
To understand the other options you need to be familiar with NFS clients: A
user level application accesses a mounted network file system as if it were any
local magnetic disk. The kernel of the client computer automatically generates
NFS requests and waits for the answers, which in turn are used to satisfy the
accesses requested by the application. But networks may drop a request or an
answer. Therefore, the NFS client built into the client's kernel not only
generates NFS requests, but also retransmits them if it does not receive a
reply within a reasonable time.
The timeo=99 option instructs the kernel's NFS client to retransmit a
request if there is no reply after 99 tenths of a second (9,9 seconds). These
retransmissions are not visible to the user, except for messages such as
"NFS server not responding, still trying". Short time-outs increase
the network load because each disk move can cause several useless
retransmissions. Long time-outs are bad if a packet is dropped by an unreliable
network and a user must wait until the kernel's NFS client retransmits the
request. After each retransmission, the time-out value is doubled, up to a
maximum of one minute.
The retrans=14 option instructs the kernel's NFS client to
automatically retransmit a request 14 times before it gives up and the file
system access that caused the NFS request fails. It makes sense to specify a
high value because if several clients access different disks located in the
same jukebox, the server must move these disks, and the last client will have
to wait a long time. You can avoid long delays if you have enough jukeboxes and
enable the server to distribute the load by duplicating the disks and spreading
them over the jukeboxes. This enables you to build failure-tolerant archives
with predictable short response times.
The soft option instructs the kernel's NFS client to give up after all
retransmissions. You can also specify hard causing the client not to
give up even after the last retransmission. If you specify an additional
intr option, the system call that caused the NFS request may be
interrupted with a signal. If you specify hard without intr
the only way to finish the system call is a server response.
If the mount command generates a message like "no such file or
directory", make sure that both directories /cd on the client
side and /views_rr on the server side exist. If you receive a
"permission denied" message, just export /views_rr on the
server side.
If
your client computer uses a PC operating system such as DOS or NT, you can
install an NFS client on the PC or install a PC file server such as samba on
the server computer. You can obtain samba from the iXOS ftp server
ftp.ixos.de/pub/jukeman, or from samba.anu.edu.au, under
pub/samba. The latest version of samba is included with iXOS-JUKEMAN.
You can find more information about this package at the samba web site,
http://samba.anu.edu.au.
Macintosh
clients can access iXOS-JUKEMAN running on NT 4.0. You need to install the
"Services for Macintosh" from the NT 4.0 CD via Start -> Settings
->Control Panel -> Network -> Services.
Once this service is installed, a virtual volume can be created with the File
Manager winfile.exe (not with the Windows NT Explorer!). This volume
can be accessed by Macintosh clients using an NT share name.
The File Services for Macintosh do not notify changes to the file system to the
clients. If you insert a new CD, the Services for Macintosh have to be stopped
and restarted to make this CD visible to the Mac clients.