Distributed filesystems provide a number of administrative advantages, most of which were highlighted in the first article in this series. For real users, the biggest advantages of distributed filesystems are that they give you access to a greater amount of storage than most desktop or laptop systems contain, and that they can be accessed from any authorized workstation. However, accessing distributed filesystems from different systems can be confusing if the filesystem doesn't provide a single way of accessing those files.

Anyone who has ever used Windows shared filesystems and directories (usually referred to as "shares") is probably familiar with the frustration of the fact that different drive letters are often mapped to different shares on different computers. For example, the filesystem mapped to the drive letter F: on one system is often different than the filesystem mapped to the same drive letter on another. This makes it difficult to tell other people how to find a specific file or directory--sending email asking your business partners to review the file F:\projects\startup\bus_plan.txt will only frustrate prospective business partners if your drive F: and theirs are mapped to two different shares.

Distributed filesystems such as Coda (and AFS) eliminate this problem by providing a single way of accessing the distributed filesystem that is the same on all computer systems. The entire Coda distributed filesystem on any workstation is mounted under the directory /coda (Not surprisingly, AFS uses the /afs directory for the same purpose.) This is referred to as a "global name space" because it means that all Coda systems in each administrative domain share the exact same view of the Coda distributed filesystem. Users can therefore locate familiar files and directories that are stored in Coda can be accessed from any machine through the same pathname. If your home directory is /coda/home/wvh, that same directory is available from any other systems in the same administrative Coda domain by using the same pathname. As explained later in this article, installing a Coda client provides an instant example of this by enabling you to access a special, open shared directory at CMU as soon as you start Coda on your system.

Another significant advantage of Coda is that it provides support for a much richer set of file and directory permissions than standard Linux/Unix systems do. These permissions are known as Access Control Lists (ACLs). Standard Linux file and directory permissions let you restrict access based on the owner of a file, a group that is associated with that file or directory, and set default permissions for everyone else. In Coda, as in AFS, you can set explicit permissions for any number of individuals or existing groups. You can also create your own groups, add users to them, and then grant special sets of permissions to the group as a whole. Access control lists are not unique to Coda and AFS--they are also available in journaling filesystems such as XFS. Work to add support for access control lists is also underway for standard Linux filesystems such as ext2 and ext3.

The best example of the advantage of Access Control Lists is the flexibility that they provide when working on special projects. If you are using a standard Linux system, you could ask your system administrator to create a Linux group for the project, add all of the project members to that group, and then ask him or her to create a directory owned by that group. When working on files in that directory, users would have to use the Linux newgrp command to change their active group membership to the project group, and then keep an eye on file and directory permissions when working on those files to ensure that they don't accidentally save files with protections that would prevent anyone in the group from subsequently editing those files.

In contrast, when using Coda ACLs, any user can create their own shared directory in the Coda filesystem, create a project group, and assign users to that group. All Coda users who are added to the group instantly have access to those files because Coda users can simultaneously belong to multiple groups. Any files and subdirectories created in the project directory automatically inherit the permissions of the parent directory. No current or future intervention from a system administrator is required--the Coda user who owns the group can add or remove members at any time.

Support for the Coda filesystem is present in the source code for all 2.4 kernels and comes pre-compiled as a loadable kernel module (LKM) in many recent out-of-the-box Linux distributions, including Red Hat 7.3. An easy way to see if support for Coda is compiled into your kernel is to examine the file /proc/filesystems after booting your system. If an entry for Coda is present in this file, support for Coda is compiled into your kernel. If not, use the su command to become the root user and try loading the Coda loadable kernel module using the command insmod coda. If this command does not display an error message, it displays the full pathname of the Coda kernel module that it has just loaded, you're ready to run a Coda client, as explained in the next section.

If your kernel does not already contain active Coda support and no Coda LKM is already available, you will need to have installed the kernel source code for the version of the kernel that your system is running. If installed, it should be located in a subdirectory of your /usr/src directory that has the same name as your kernel version. If it is not installed, a package containing the kernel source code for your Linux distribution should be available on your distribution disks.

Once you've located the kernel source code, execute the command make xconfig to display the Linux kernel configuration's X Window system-based kernel configuration mechanism. The Coda option is located in the dialogs displayed by make xconfig in the "File Systems" panel's "Network File Systems" panel. Select m beside the "Coda file system support (advanced network fs)" entry to build this as a loadable kernel module, and exit from make xconfig, saving your changes. You can then execute the make dep, make modules, and make modules_install. You will need to do this on both your client and server systems. Once the module is compiled and installed, you can then use the insmod command described earlier in this section to verify that the module compiled correctly and could be correctly installed on your system.

Next: Installing a Coda Client »