3. Organization of data

This chapter how data is stored and how AFS diffrent from, for example, NFS. It also describes how data kept consistent and what the requirements was and how that inpacted on the design.

3.1 Requirements
3.3 Volume
3.7 Callbacks
3.8 Volume management
3.9 Relationship between pts uid and unix uid

3.1 Requirements

• Scalability

  It should be possible to use AFS with hundred-thousands of users without problems.

  Writes that are done to diffrent parts of the filesystem should not affect each other. It should be possible to distribute out the reads and writes over many file-servers. So if you have a file that is accessed by many clients, it should be possible to distribute out the load.

  If there is multiple writes to the same file, are you sure that isn't a database.

• Transparent to users

  Users should not need to know where their files are stored. It should be possible to move their files while they are using their files.

• Easy to admin

  It should be easy for a administrator to make changes to the filesystem. For example to change quota for a user or project. It should also be possible to move the users data for a fileserver to a less loaded one, or one with more diskspace available.

  Some benefits of using AFS is:

  • user-transparent data migration
  • an ability for on-line backups;
  • data replication that provides both load balancing and robustness of critical data
  • global name space without automounters and other add-ons;
  • @sys variables for platform-independent paths to binary location;
  • enhanced security;
  • client-side caching;

3.2 Anti-requirements

• No databases

  AFS isn't constructed for storing databases. It would be possible to use AFS for storing a database if a layer above provided locking and synchronizing of data.

  One of the problems is that AFS doesn't include mandatory byte-range locks. AFS uses advisory locking on whole files.

  If you need a real database, use one, they are much more efficent on solving a database problem. Don't use AFS.

3.3 Volume

A volume is a unit that is smaller then a partition. Its usually (should be) a well defined area, like a user's home directory, a project work area, or a program distribution.

Quota is controlled on volume-level. All day-to-day management are done on volumes.

3.4 Partition

In AFS a partition is what normally is named a partition. All partions that afs isusing is named a special way, `/vicepNN', where NN is ranged from a to z, continuing with aa to zz. The fileserver (and volser) automaticly picks upp all partition starting with `/vicep'

Volumes are stored in a partition. Volumes can't overlap partitions. Partitions are added when the fileserver is created or when a new disk is added to a filesystem.

3.5 Volume cloning and read-only clones

A clone of volume is often needed for the volume operations. A clone is copy-on-write copy of a volume, the clone is the read-only version.

A two special versions of a clone is the read-only volume and the backup volume. The read-only volume is a snapshot of a read-write volume (that is what a clone is) that can be replicated to several fileserver to distribute the load. Each fileserver plus partition where the read-only is located is called a replication-site.

The backup volume is a clone that typically is made (with vos backupsys) each night to enable the user to retrieve yestoday's data when they happen to remove a file. This is a very useful feature, since it lessen the load on the system-administrators to restore files from backup. The volume is usually mounted in the root user's home directory under the name OldFiles. A special feature of the backup volume is that inside it you can't follow mountpoint.

3.6 Mountpoints

The volumes are independent of each other. To clue the together there is a `mountpoint's. Mountpoints are really symlink that is formated a special way that points out a volume (and a optional cell). A AFS-cache-manager will show a mountpoint as directory, in fact it will be the root directory of the target volume.

3.7 Callbacks

Callbacks are what enable the AFS-cache-manager to keep the files without asking the server if there is newer version of the file.

A callback is a promise from the fileserver that it will notify the client if the file (or directory) changes within the timelimit of the callback.

For read-only callbacks there is only callback given its called a volume callback and it will be broken when the read-only volume is updated.

The time range of callbacks range from 1 hour to 5 minutes depending of how many user of the file exists.

3.8 Volume management

All volume managment is done with the vos-command. To get a list of all commands `vos help' can be used. For help on a specific vos subcommand, `vos subcommand -h' can be used.

• Create

  vos create mim c HO.staff.lha.fluff -quota 400000

• Move

  Volumes can be moved from a server to another, even when users are using the volume.

• Replicate

  Read-only volumes can be replicated over several servers, they are first added with vos addsite, and the replicated with vos release out over the servers.

• Release

  When you want to distribute out the changes in the readwrite volume.

• Remove

  Volumes can be removed

  Note that you shouldn't remove the last readonly volume since this make clients misbehave. If you are moving the volume you should rather add a new RO to the new server and then remove it from the old server.

• Backup and restoration of volumes.

  vos backup and vos backupsys creates the backup volume.

  To stream a volume out to a `file' or `stdout' you use vos dump. The opposite command is named vos restore.

3.9 Relationship between pts uid and unix uid

foo