COMPUTER AND NETWORK
SYSTEM ADINISTRATION
CIS 5406-01
Summer 1999 - Lesson 8
The Network File System
Reference: Page 607 in ESA
A. Introduction to NFS
- What was life like before NFS?
- Built on top of:
UDP - User Datagram Protocol (unreliable delivery)
XDR - eXternal Data Representation (machine independent data format)
RPC - Remote Procedure Call
1. NFS is both a set of specifications and an implementation
2. The protocol specifications are independent of architecture
and operating system
3. Two protocols - mount protocol and NFS protocols
- mount protocol establishes initial link between client and
server machines
- NFS protocols provide a set of RPCs for remote file
operations
> Searching a directory
> Reading a set of directory entries
> Manipulating links and directories
> Accessing file attributes
> Read and writing files
> Notably missing are open() and close()
> There is no equivalent to UNIX file tables on the server
side (therefore NFS is stateless on the server side)
> Each request must provide full set of arguments including
a unique file identifier and offset
4. problems
- Performance (even with UDP)
> Modified data may be cached locally on the client
> Once the cache flushes to the server, the data must be written to
disk before results are returned to the client and the cache
is flushed
- Semantics
> UNIX semantics (without NFS)
+ Writes to an open file are visible immediately to other
users who have the file open at the same time
+ The file is viewed as a single resource
> Session semantics (ala Andrew file system)
+ Writes to an open file are not visible to others having
it open at the same time
+ Once a file is closed the changes are visible only in
the sessions opened later
> NFS claimed to implement UNIX semantics
+ there are two client caches: file blocks and file attributes
+ cached attributes are validated with server on an open()
+ the biod process implements read-ahead and delayed-write techniques
+ newly created files may not be visible to other sites for
up to 30 seconds
+ it is indeterminate whether writes to a file will be immediately
seen by other clients who have the file open for reading
- If a single NFS stat() request hangs, it can hang up UNIX commands,
like "df"!
- "magic cookies" (random numbers) used to short-cut future
validations. Given to client from server, client can use it
to re-connect whenever a server comes back up after a crash.
--> Can be spoofed <-- Note that "stale cookies" (yuck) can
make a client hang (solution: remount the filesystem on the
client to make it get a new, fresh cookie).
B. Server
1. mountd - Sun's UNIX implementation of the mount protocol
- SunOS 4.x reads /etc/exports (as does Linux NFS)
- uses "exportfs" to have mountd reload table ("exportfs -a")
- example: /etc/exports
/real/cs25 -access=host1:host2:host3,root=host2
- SunOS 5.x reads /etc/dfs/dfstab
- Uses "share" to have mountd reload the kernel's export table
- Example: export:/etc/dfs/dfstab
share -F nfs -o rw=host1:host2:,root=host2 /real/cs15
- Linux (Slackware and RedHat, at least) uses /etc/exports and "kill -HUP"
to mountd. The syntax of the file, alas, is different. Sample
Linux /etc/exports:
/real/majors *.cs.fsu.edu(ro) pleiades(no_root_squash)
2. nfsd
- Handles requests for NFS file service
- Very small, basically turn around and call kernel
C. Client side
1. Extended "mount" command, accepts "host:path" syntax for NFS filesystems
- /etc/vfstab in SunOS 5.x
- example:
#device device mount FS fsck mount
#to mount to fsck point type pass boot
#-----------------------------------------------------------------------
/proc - /proc proc - no
fd - /dev/fd fd - no
swap - /tmp tmpfs - yes
/dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0 / ufs 1 no
/dev/dsk/c0t3d0s6 /dev/rdsk/c0t3d0s6 /usr ufs 2 no
/dev/dsk/c0t3d0s5 /dev/rdsk/c0t3d0s5 /opt ufs 5 yes
/dev/dsk/c0t3d0s1 - - swap - no
- Type "mount" to see currently mounted file systems
- example:
/dev/sd0a on / type 4.2 (rw)
/dev/sd0g on /usr type 4.2 (rw)
host5:/real/cs4 on /tmp_mnt/home/cs4 type nfs (rw,suid,hard,intr)
host6:/real/cs5 on /tmp_mnt/home/cs5 type nfs (rw,nosuid,hard,intr)
host7:/real/cs23 on /tmp_mnt/home/cs23 type nfs (rw,nosuid,hard,intr)
2. NFS service is provided in kernel
- transparent to user
3. biod
- Provides read-ahead and write-behind caching
D. Administering NFS
1. User must have account on file server or access rights can't be checked.
2. must keep UIDs and GIDs consistent across machines
3. Don't mount outside of local net (can block NFS protocol at router)
E. Auto-mounting
1. Sun's "automount" daemon (used on CompSci network)
- Why mount all filesystems that a host may possibly use when
you can have them mounted and unmounted based on demand?
This saves kernel space and reliance on dead NFS servers.
- Nice to keep one NIS automount map instead of ~50 /etc/fstab
maps
Operation (using CompSci mappings):
- The automounter appears to the kernel to be an NFS server
- Automount uses its maps to locate a real NFS file server
- It then mounts the file system in a temporary location
(like /tmp_mnt) and creates a symbolic link to the temporary location
- If the file system is not accessed within an appropriate
interval (five minutes by default), the daemon unmounts the
file system and removes the symbolic link
- If the indicated directory has not already been created, the
daemon creates it, and then removes it upon exiting.
- Example (somewhat convoluted) configuration maps:
- auto.master (available via a NIS file; "ypcat -k auto.master")
/home auto.home # an indirect map all rooted at "/home"
/- auto.direct # "/-" means a direct map
/net -hosts -rw,nosuid,hard,intr
# "-host" means use
# NIS "host.byname" to look
# up the hostname; will
# mount any permissible
# NFS server on "/net/..."
- auto.direct ("ypcat -k auto.direct")
Path mount() options actual location
---- --------------- ---------------
/nu0 -rw,nosuid,hard,intr sync:/real/nu0
/nu1 -rw,suid,hard,intr sync:/real/nu1
/nu2 -rw,suid,hard,intr sync:/real/nu2
/var/spool/mail -rw,nosuid,hard,intr nu:/usr/spool/realmail
- auto.home ("ypcat -k auto.home")
Path mount() options actual location
---- --------------- ---------------
cs4 -rw,suid,hard,intr server1:/real/cs4
cs5 -rw,nosuid,hard,intr server2:/real/cs5
.
.
.
cs38 -rw,nosuid,hard,intr server5:/real/cs38
2. "amd" - The Auto Mount Daemon; public domain automounter from
Jan-Simon Pendry's doctoral thesis (used on CompSci's Linux machines)
- New features; more flexible
- Irritating features of the Sun implementation were improved:
> amd does not hang if a remote file system goes down
> amd attempts to mount a replacement file system if and
when they become available
- amd automatically unmounts (via "keep-alive")
- non-blocking operation
- amd maps can be just as convoluted:
/etc/amd.master
-r -x all -a /tmp_mnt
/home /etc/amd.home
/tmp_mnt/direct /etc/amd.direct
/etc/amd.home
/default -opts:=rw,nosuid,hard,intr,rsize=8192,wsize=8192
cs5 host!=server1;type:=nfs;rhost:=server1;rfs:=/real/cs5
cs6 host!=server2;type:=nfs;rhost:=server2;rfs:=/real/cs6
/etc/amd.direct
/default -opts:=rw,nosuid,hard,intr,rsize=8192,wsize=8192
mail host!=nu;type:=nfs;rhost:=nu;rfs:=/var/spool/mail
F. Security
Don't export to hosts for which non-trusted users have root access.
If you don't control root on the machine then don't export the file system.
Block NFS UDP traffic at your router, if possible.
G. Tuning NFS
You can adjust the number of nfsd and biods
Use nfsstat -c to see client-side NFS traffic
Use nfsstat -s to see server-side NFS traffic
Tuning with mount command:
rsize=n Set the read buffer size to n bytes.
wsize=n Set the write buffer size to n
bytes.
timeo=n Set the NFS timeout to n tenths of a
second.
retrans=n The number of NFS retransmissions.
H. Beyond NFS
o AFS - Andrew File System, from CMU and Transarc Corp.
- Much better authentication (Kerberos)
- 8 inch high stack of installation books!
- Adds new file system type to kernel
- Addresses more than just file system semantics, also
user authentication, etc.
- Large local client-side disk cache improves performance
o DFS - Distributed File System from OSF
- "successor" to AFS; AFS-like
- Beginning to show up in most vendor's UNIX implementations,
as well as non-UNIX operating systems
- Major part of DCE (Distributed Computing Environment)
Windows NT Shares
Chapter 5 of EWNTSA gives information about Shares. A share is
a directory or other resource, such as a printer or CD-ROM drive,
that is designated to be used among network users.
Shares achieve a similar effect as between an NFS server and client,
with much less fuss :)
Creating a share is simple: right-click on the drive or directory
and select the Sharing option.
You can also create multiple share names for the same device/directory.
Think of it as NFS-mounting the same file system at more than one
place in the file system hierarchy. To do so, from within Explorer you
can use the Share As option from the Disk menu or click on the Share
icon on the toolbar.