<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9"> <TITLE>Coda File System User and System Administrators Manual: System Administration: Volumes </TITLE> <LINK HREF="manual-11.html" REL=next> <LINK HREF="manual-9.html" REL=previous> <LINK HREF="manual.html#toc10" REL=contents> </HEAD> <BODY> <A HREF="manual-11.html">Next</A> <A HREF="manual-9.html">Previous</A> <A HREF="manual.html#toc10">Contents</A> <HR> <H2><A NAME="SysAdmVol"></A> <A NAME="s10">10. System Administration: Volumes </A></H2> <P> <P> <H2><A NAME="ss10.1">10.1 Description</A> </H2> <P> <P>Although users view the Coda file system as a hierarchy of directories and files, system administrators view the Coda file system as a hierarchy of volumes. Each volume contains a subtree of related directories and files which is a subtree of the entire file system. Volumes, then, parallel traditional Unix file systems. Like a Unix file system, a volume can be mounted. Thus, the root of a volume can be named within another volume at a mount point. The Coda file system hierarchy is built in this manner and is then mounted by each client using a conventional Unix mount point within the local file system. Since all internal mount points are invisible, the user sees only a single mount point for the entire Coda file system. <P>All system administration tasks are performed relative to a volume or a set of volumes. So, adding new users requires creating new volumes for their files and directories; quotas are enforced on volumes; and backups are performed on a per-volume basis. The volume abstraction greatly simplifies the administration of large systems. <B>NOTE: Quotas have not been implemented yet</B>. <P>The Coda file system provides four different types of volumes. The simplest of these is the <EM>non-replicated volume</EM>. Non-replicated volumes reside on a single server and are in the custody of the Coda file server they reside on. The Coda servers work with the venus processes on client workstations to provide a single, seamless view of the file system. However, if a custodian crashes or is otherwise inaccessible, its non-replicated volumes are inaccessible as well. <P>To partially solve this availability problem, Coda provides <EM>replicated, read-only volumes</EM>. This type of volume has exactly one read-write copy, but may have any number of read-only copies controlled by other servers. Changes to such a volume are made on the custodians read-write copy and then distributed to all servers with read-only copies. Read-only replication provides higher availability for volumes containing frequently-requested but infrequently-updated objects, like system binaries. In addition, read-only replication is used in performing backups on volumes. <P>Unfortunately, read-only replicas cannot provide high availability for all types of volumes, e.g. user volumes. Thus, Coda also provides <EM>read-write, replicated volumes</EM>. Read-write, replicated volumes are logical volumes which group together multiple read-write, non-replicated volumes. Coda provides protocols which allow read-write, replicated volumes to reside on a number of servers and to be accessed even when some servers are inaccessible. Although read-write replication provides everything read-only replication provides, its protocols are more expensive. Thus, read-only replication, rather than read-write replication, should be used for volumes which change slowly but are accessed frequently. Table <A HREF="#VolTypes">XXX</A> illustrates the differences between the volume types. <P> <CENTER><TABLE BORDER><TR><TD> <BR> <B>Volume Type</B></TD><TD><B>Where Reads</B></TD><TD>bf/Where Writes/</TD><TD><B>Conflicts</B></TD></TR><TR><TD> </TD><TD><B>Performed</B></TD><TD><B>Performed</B></TD><TD><B>Possible?</B></TD></TR><TR><TD> Non-replicated</TD><TD>Only Custodian</TD><TD>Only Custodian</TD><TD>No</TD></TR><TR><TD> Read-only Replicated</TD><TD>Any Server with</TD><TD>Only Custodian</TD><TD>No</TD></TR><TR><TD> </TD><TD>Replica</TD><TD></TD><TD></TD></TR><TR><TD> Read-Write Replicated</TD><TD>Any VSG Member</TD><TD>Any VSG Member</TD><TD>Yes</TD></TR><TR><TD> Backup</TD><TD>Only Custodian</TD><TD>Nowhere</TD><TD>No</TD></TR><TR><TD> <CAPTION>Coda Volume Types <A NAME="VolTypes"></A> </CAPTION> </TD></TR></TABLE></CENTER> <P> <P> <H2><A NAME="CreateVol"></A> <A NAME="ss10.2">10.2 Creating a Volume </A> </H2> <P> <P>Typically, volumes consist of a single users data objects or other logically connected groups of data objects. Four factors should be used in dividing the file system tree into volumes. <P> <OL> <LI>The volume is the unit of quota enforcement and, potentially, accounting.</LI> <LI>The rename command is prohibited across volume boundaries. Thus, manipulation of the tree structure at a granularity other than a whole volume (e.g. moving the mount point) or less than a volume (e.g. moving directories or files within a volume) is expensive. Moving a subtree of a volume to another volume requires copying every byte of data in the subtree.</LI> <LI>The size of the volume should be small enough that moving volumes between partitions is a viable approach to balancing server disk utilization and server load. Thus, volumes should be small relative to the partition size.</LI> <LI>Finally, the size of a volume must not exceed the capability of the backup media. </LI> </OL> <P> <P>A volume naming convention should also be used by those administrators who create volumes. Volume names are restricted to 32 characters and should be chosen so that given a volume name, a system administrator (who knows the naming conventions) can determine its correct location in the file system hierarchy. The convention used by the Coda project is to name volumes by their function and location. Thus, a replicated volume named "u.hbovik" is mounted in <CODE>/coda/usr/hbovik</CODE> and contains hboviks data. A project volume is prefixed by "p." and a system volume is prefixed by "s." Similarly, volumes containing machine specific object files are prefixed by the machine type. For instance, "p.c.alpha.pmax.bin" contains project coda binaries for our current alpha release and is mounted on <CODE>/coda/project/coda/alpha/pmax_mach/bin</CODE>. <P>Use the commands <CODE>createvol (8)</CODE> and <B>createvol_rep</B>(8) to create non-replicated and read-write replicated volumes respectively. (Read-only replication is discussed in Section <A HREF="#RORep">XXX</A> below). These commands are actually scripts which ultimately invoke the <CODE>volutil (8)</CODE> command with the create option at the appropriate server. The volume will contain an access list initialized to <B>System:AnyUser rlidwka</B>. Creating the volume does not mount the volume within the file system hierarchy. Mounting the volume as well as changing the access list or the quota must be done using the <CODE>cfs (1)</CODE> command from a client. A new volume may not be visible at client workstations for some time (see Section <A HREF="#VLDB">XXX</A> below). <P>A few concrete examples should clarify the use of some of these commands. On the SCM, the command <P> <PRE> * createvol u.hbovik mahler /vicepa </PRE> <P>will create a non-replicated volume named "u.hbovik" on server "mahler"s /vicepa partition. Similarly, the command <P> <PRE> * createvol_rep u.hbovik E0000107 /vicepa </PRE> <P>will create a replicated volume named "user.hbovik" on each server in the Volume Server Group (VSG) identified by "E0000107". The file <CODE>/vice/db/VSGDB</CODE> contains the mapping between VSGs and their identifications. The names of the replicas will be "user.hbovik.n", where n is a number between 0 and |VSG| - 1. <P> <P> <H2><A NAME="ss10.3">10.3 Mounting a Volume</A> </H2> <P> <A NAME="MountVolume"></A> <P>In order to use a volume which you have created and added to the appropriate databases, you must mount the volume. Although Unix file systems must be mounted upon reboot in Unix, Coda volumes are mounted only once. To mount a Coda volume, you must be using a Coda client and be authenticated as a user (use the <B>clog) command</B> who has write access to the directory in which the mount point will be created. <P>Mount the volumes using the command <P> <PRE> * cfs mkmount <filename> volname </PRE> <P>Note that cfs creates <filename> automatically. For example, <P> <PRE> * cfs mkmount /coda/usr/hbovik u.hbovik </PRE> <P>will create <CODE>/coda/usr/hbovik</CODE> and then mount the <B>u.hbovik</B> volume created in the example in Section <A HREF="#CreateVol">XXX</A>. The volume is now visible to all users of the Coda file system. When mounting a volume, avoid creating multiple mount points for it. Coda cannot check for this. More information about the <B>cfs</B> command can be found in Chapter <A HREF="manual-2.html#GettingStarted">XXX</A> as well as in Appendix <A HREF="manual-19.html#ManPages">XXX</A>. <P> <H2><A NAME="DeleteVol"></A> <A NAME="ss10.4">10.4 Deleting a Volume </A> </H2> <P>When a volume is no longer needed, it may be purged by running the <B>purgevol</B> or <B>purgevol_rep</B> scripts on the SCM. Before removing a volume, you should probably create a backup for offline storage (see Section <A HREF="#RORep">XXX</A> up to the restore step). The volume's mount point should be removed with the <B>cfs</B>(1) command (see the rmmount option) before purging the volume (if possible). Note that purging the volume will not purge related backup volumes. Backup and ReadOnly volumes should be purged with the <B>purgevol</B> script. <P> <P> <H2><A NAME="ss10.5">10.5 Restoring a Volume</A> </H2> <P>For complete details on the backup/restore process, see Chapter <A HREF="manual-12.html#Backup">XXX</A>. In short, one first needs to get the correct dumpfile, possibly merging incremental dumps to an older full dump to get the desired state to be restored. Once this file is obtained, use the <B>volutil (8)</B> restore facility. <P> <PRE> * volutil restore <filename> <partition> [<volname> [<volid>]] </PRE> <P>The <partition> should be one of the <CODE>/vicep?</CODE> partitions on the server. You may optionally specify the volumeid and the volume name for the restored volume. This is useful when creating read-only replicated volumes. Note that currently dump files are not independent of byte ordering -- so volumes cannot be dumped across architectures that differ in this respect. <P> <H2><A NAME="RORep"></A> <A NAME="ss10.6">10.6 Read-only Replication of a Volume </A> </H2> <P>Read-only replication of a volume requires more effort on the part of the system administrator. However, it greatly increases the availability of volumes which cannot be read-write replicated. The most important example of such a volume is the root of the Coda file system. Conflicting updates cannot be allowed to occur at the root volume since this would make the entire Coda file system inaccessible. However, if the root volume is not replicated, the availability of the entire Coda file system depends upon the availability of the server acting as the custodian for this one volume. For these reasons, we highly recommend making the root volume of the Coda file system read-only replicated. We provide an extended example here to show you exactly how to go about the replication and distribution process. Note that the example shows how to make the root read-only replicated. Details pertaining to the coda root volume can be ignored when making other read-only replicated volumes (such as subtrees containing standard binaries). <P>We assume that you have a non-replicated root volume, called <B>coda.root</B>. If you are installing a new system, you can access this volume as /coda by using a Coda client. This volume should look exactly how you want the read-only replica to look. If it doesnt, make any changes now. Also note that any volumes that you want mounted within the read-only replicas should be mounted before continuing. Our root volume has three read-write replicated volumes mounted. The <CODE>usr</CODE> volume contains the home directories of our users, the <CODE>project</CODE> volume contains project directories and <CODE>tmp</CODE> contains temporary files. In addition, we have one subdirectory called <CODE>nonrep</CODE> which has non-replicated volumes (one per server) mounted within it. The purpose of these non-replicated volumes is to provide users with a location to perform repairs of conflicting objects. (Although the need for such a directory may not be clear at this point, we highly recommend providing such a directory.) <P>If you already have a read-only replicated root volume but want to update it, you should mount the read-write version of the root volume elsewhere and make your changes to this volume. Once you have made your changes, you will need to purge the old read-only replicas of your root volume using the <B>volutil(8)</B> command. Be sure that you purge the replica on each server. Then, you will need to edit the VolumeList file in <CODE>/vice/vol</CODE> and remove the entry for the read-only replicated root volume. (The name of the read-only replica will probably be coda.root.readonly.) <P>On the SCM, you need to clone the read-write copy of the root volume. You can use the command <P> <PRE> * volutil clone <VolumeId> </PRE> <P>This command will create a read-only volume with the name <B>coda.root.readonly</B> (Assuming that your root volume is called <B>coda.root)</B>. Next, you will need to dump this cloned volume to a file with the command <P> <PRE> * volutil dump <VolumeId> <filename> </PRE> <P>Now, copy this file to each of the servers which will have read-only replicas of the root volume and execute the command <P> <PRE> * volutil restore <filename> <partition> [<volid> [<volname>]] </PRE> <P>Note that the root volume currently must reside on <CODE>/vicepa</CODE>. Read-only replicated volumes must share the same volid and name, so take care to specify these correctly when restoring to more than one server. The final step is to build the VLDB by running the command <P> <PRE> * bldvldb.sh </PRE> <P>on the SCM and to make sure that the file <CODE>/vice/ROOTVOLUME</CODE> contains the name or volume id of the root volume (coda.root.readonly). (Also, it may be necessary to restart the venus on the clients.) <P> <H2><A NAME="VLDB"></A> <A NAME="ss10.7">10.7 Building the VLDB </A> </H2> <P> <P>The volume location data base, VLDB, is used to provide volume addressing information to workstations. Copies of the VLDB reside on the servers and are updated periodically. The VLDB lists the latest known location or locations of all on-line volumes in the system. A human readable version of the VRDB is maintained on the SCM in the file <CODE>/vice/vol/VRList</CODE>. <P>The VLDB is maintained on the SCM. When you wishe to update it, run the <B>/vice/bin/bldvldb.sh (8)</B> script on the SCM. The script gathers a copy of the <CODE>/vice/vol/VolumeList</CODE> file from all the servers, merges it into a single list, and builds a new VLDB. The UpdateMon program then propagates the new VLDB to all the servers. Note that the <B>createvol</B> and <B>purgevol</B> scripts automatically invoke <B>bldvldb.sh</B>. <P> <H2><A NAME="ss10.8">10.8 Building the VRDB</A> </H2> <P> <P>The volume replication data base, the VRDB, is used to provide information about replicated volumes to client workstations. Copies of the VRDB reside on all servers and are updated periodically. The VRDB maps each logical volume to its corresponding set of physical volumes. <P>A human readable version of the VRDB is maintained on the SCM in the file <CODE>/vice/vol/VRList</CODE>. The <B>makevrdb</B> option to the <B>volutil(8)</B> command will create a new VRDB which will automatically be distributed to the other servers. <P> <H2><A NAME="ss10.9">10.9 Building the VSGDB</A> </H2> <P> <P>The Volume Storage Group Data Base, VSGDB, is currently maintained by hand. Each valid volume storage group has an entry in this data base containing an identification number and the names of the servers in the group. <P> <H2><A NAME="ss10.10">10.10 Ensuring Volume Consistency after Server Crashes</A> </H2> <P> <P>Coda servers ensure file system consistency after a crash by running <B>fsck (8)</B>, recovering RVM, and running the Coda salvager. The <B>fsck</B> used here a CMU has been modified so that it does not require every inode to be referenced by a <BLOCKQUOTE><B>Warning</B>: the vanilla <B>fsck</B> must not be used on a Coda file system partition as the Coda files will be thrown away.</BLOCKQUOTE> Coda accesses inode directly. After the server machine is booted, the <B>codasrv</B> process starts and RVM recovers the servers committed state. The Coda salvager then reconciles the results from <B>fsck</B> and the salvager. <P> <H2><A NAME="ss10.11">10.11 Getting Volume Information</A> </H2> <P> <P>The <B>cfs</B> provides information on volumes. <B>cfs</B> can only be used on a machine which has a running <EM>venus</EM> (such as a client workstation). <B>cfs</B> is described in Chapter <A HREF="manual-2.html#GettingStarted">XXX</A> as well as in the manual page contained in Appendix <A HREF="manual-19.html#ManPages">XXX</A>. <HR> <A HREF="manual-11.html">Next</A> <A HREF="manual-9.html">Previous</A> <A HREF="manual.html#toc10">Contents</A> </BODY> </HTML>
distrib
>
Mandriva
>
8.2
>
i586
>
media
>
contrib
>
by-pkgid
>
211238da6d926d1ca4390483bb29f586
>
files
>
27
