The Unified Storage Device (USD) exports data as files through two primary protocols, NFS and CIFS, which correspond to the UNIX and Windows processes. USD can also export data as blocks, through FCP or iSCSI, like a traditional SAN-attached disk array.
When you browse directories, some are not on the local disk of your computer, but are mounted from a remote server. The name of the directory is called a mount point. All the files and directories below the mount point actually exist on the remote server.
UNIX and Windows have different terminology, and very different file sharing protocols. What gets exported on a UNIX server is called a file system, and is usually specified in the system file /etc/fstab. An exportfs command is often involved on the remote host.
For example, a local host wants to mount the file system /usr/users on remote server server1 over the existing local directory /users. Following is the command syntax:
# mount server1:/usr/users /users
After this is done, the NFS file sharing protocol is used to retrieve the files from the remote server just as they are accessed by the user from a local workstation. If there were files in the directory /users before the mount was done, they are no longer visible until the file system is unmounted. A pictorial representation of the arrangement looks like this:
In the preceding illustration, a UNIX workstation has five directories on its local disk: /, /bin, /etc, /home, and /applications. The home directory has two subdirectories, users and users2. Three remote file systems are mounted over the directories /home/users, /home/users2, and /applications. Each of these directories is called a mount point. Files in the directories are accessed through NFS, and obey the UNIX file semantics.
System administrators often set up the mount points to occur automatically when users log in and when the servers start up. In such a case, the user does not know where the data is located. Usually the file servers are located in a centralized place to the enterprise, where they are administered and their data is backed up.
Accessing remote files might seem slower, but this is not always the case. Especially over gigabit LANs, getting data from USDs is frequently faster than getting it from a local disk. This is partially because of RAID striping, which allows pieces of a file to be read simultaneously that are on separate disks.
Windows uses the CIFS file sharing protocol. What gets exported on a Windows server is known as a share, and is usually specified through the GUI using the Sharing menu item that pops up when you right-click a folder in the Windows Explorer.
For example, assume that a local host wants to mount a remote share called users on the server server1, and call it the drive G:. To do this, you could browse My Network Places to the machine server1, and then to server1's share named users. You can assign the drive G: to it. Otherwise, you could use the following a command:
> net use G: \\server1\users
Either way drive G: is mounted on server1's share named users, and all the files and subdirectories in the remote share users appear as though they were local files in the G: drive. This drive is called a network drive. The CIFS protocol is used to retrieve the files and the directory listings as they are accessed by the user logged the local workstation.
In the preceding illustration, a Windows workstation has one local drive and four network drives. Files in the drives are accessed through CIFS, and they obey Windows file semantics.
Drive E: is mapped to the user's homedir share, which is a special feature of Data ONTAP, the USD OS. What the user sees in E:\ is the same as that seen in D:\zoe, for a user named zoe.
The case for centralizing Windows file storage on USDs is very similar to that in NFS.
As in NFS, getting data from USDs is frequently faster than from local disk. A known exception is compilation of Visual C++ projects, which do many tiny writes to program database files, and so are slowed down by network latencies.
The important thing to notice, when comparing these two pictures, is that you see the same files whether the remote file system is mounted through NFS or CIFS. There are some inevitable confusions over this, because the two systems have different authentication and privilege models and so on, but all in all, end users seem to get along well with the solution. A key part of this solution, for administrators, is synchronizing the account names between Windows and UNIX, which is discussed in another topic.
Related Topics