IT 4100 : File Systems and Storage Technologies

NFS

Remote Filesystems

Up until now, we have focused on local storage systems.

What is a remote filesystem? Benefits? Drawbacks? When would you use one?

What is NFS

• Network File System
  • Platform independent (although not often used with windows)
  • developed by Sun (now is an open standard)
  • Client/server model
  • Implemented through RPC and files are available over network via VFS
• Virtual File System (VFS)
  • Interface on top of Tcp/ip layer.
  • Remote system accesses look/feel like they are local

Why NFS

• We can simplify management
  • How? (i.e. /home directories can reside on a single server and be shared to others)
  • RAID that machine
  • Still single point of failure
  • Easier to backup

Clients

• File i/o commands are given.
  
• Kernel and user-space daemons do some work
  • the client mounts the remote filesystem onto the clients local fs namespace
  • access to remote fs appear as though they were local
• Multiple clients can mount the same fs and users can share files
• This can be done at boot time (fstab)
• mount command.

Server

• mountd

When receiving a MNT request from an NFS client, rpc.mountd checks both the pathname and the sender’s IP address against its export table. If the sender is permitted to access the requested export, rpc.mountd returns an NFS file handle for the export’s root directory to the client. The client can then use the root file handle and NFS LOOKUP requests to navigate the directory structure of the export. -man page - /etc/exports - nfsd

Tidbits

• RPC - Remote procedure call -
• NFSv3 and prior were stateless, newest version is stateful nfsv4.
• v3 also had a separate service (NLM-network lock manager) to deal with file locking, v4 is built in.
• v4 uses tcp. (port 2049)
• Maybe this image will be useful.

NFS options

• See man nfs
• bg/fg
  
  • Determines how the mount command behaves if an attempt to mount an export fails.
    
  • The fg option causes mount to exit with an error status if any part of the mount request times out or fails outright. This is called a “foreground” mount, and is the default behavior if neither the fg nor bg mount option is specified.
    
  • If the bg option is specified, a timeout or failure causes the mount command to fork a child which continues to attempt to mount the export. The parent immediately returns with a zero exit code. This is known as a “background” mount.
    
  • If the local mount point directory is missing, the mount command acts as if the mount request timed out. This permits nested NFS mounts specified in /etc/fstab to proceed in any order during system initialization, even if some NFS servers are not yet available.
    

Exports options

• The file /etc/exports contains a table of local physical file systems on an NFS server that are accessible to NFS clients.
• can share to single host, network /255.255.252.0 or /22 will work
• can have wildcards in share (*.thegummibear.com)
• * matches all clients

Export options

• rw = allow read/write on volume
• async = This option allows the NFS server to violate the NFS protocol and reply to requests before any changes made by that request have been committed to stable storage (e.g. disc drive). Using this option usually improves performance, but at the cost that an unclean server restart (i.e. a crash) can cause data to be lost or corrupted.
• sync = Reply to requests only after the changes have been committed to stable storage. This is the default.
• no_subtree_check (see the man exports page)

Root squashing

nfsd bases its access control to files on the server machine on the uid and gid provided in each NFS RPC request. The normal behavior a user would expect is that she can access her files on the server just as she would on a normal file system. This requires that the same uids and gids are used on the client and the server machine. This is not always true, nor is it always desirable

It may not be desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anonymous or nobody uid. This mode of operation (called root squashing’) is the default, and can be turned off with no_root_squash.