The Coda Distributed Filesystem for Linux - page 2
Introduction to Coda
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
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
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 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.