AFS Mount Point Tracking

"That's right, kid. Never play an ace if a two will do."

Jeff Smith, Bone #2

Warning

These scripts are orphaned. Although I believe they are still useful, I no longer use AFS and am no longer maintaining these scripts. If you would like to pick up maintenance of them, please feel free. Contact me if you would like this page to redirect to its new home.

Description

AFS volumes can easily be mounted anywhere in AFS that anyone wants to put them, but we found it convenient at Stanford to have a canonical mount point for any particular volume. This helped us structure our AFS space, keep track of what a volume has been allocated for and who is using it, and discover when volumes are no longer used. We stored this information as simple Berkeley DB file in AFS, containing mappings from volume name to mount point location for every volume that we have in our cell.

The mtpt utility returns the mount point associated with a volume, the loadmtpt utility records the mount point of a volume, and the cleanmtpts utility should be run periodically on the database to purge any inaccurate or defunct volume to mount point mappings.

Maintaining this database does require some work. Stanford did all of its volume creation through the volcreate tool, which automatically runs loadmtpt when a new volume is created. Nightly, using the afsdb-load script, a list of every volume in the cell is loaded into a PostgreSQL database (generated via vos listvol), and that database is checked to ensure that there is a mount point recorded for each volume. Periodically, Stanford ran cleanmtpts to remove entries for volumes that have moved or been deleted (and then AFS administrators often have to go chase their new locations when the missing volumes show up in the nightly report).

The basic idea and the original versions of these scripts were written by Neil Crellin. I subsequently updated and expanded them. There are more complex ways of discovering this information that don't require maintaining a database (such as running the salvager in a special mode), but this approach has turned out to work quite well for us in practice.

Be aware that the change summary for these scripts reflects a later version that uses remctl and a separate backend to store volume locations directly in PostgreSQL instead of in a separate BerkeleyDB database. That version of these scripts was never packaged for general distribution.

Requirements

All of these programs are written in Perl and require Perl 5.004 or later. The mount point utilities require the standard Perl DB_File module, which means that Perl must be built with Berkeley DB support (the Perl that comes with Linux distributions basically always is, but if you built Perl yourself, you may need to make sure that you had the Berkeley DB libraries available when you built it).

All of these programs work with AFS, so they obviously require the AFS fs utility be available. They search for fs in a few locations, but you may want to change the search logic yourself.

You will likely need to customize paths in these scripts for your site, customize the guessing rules for mount point locations, and fix the path to Perl. See the Site configuration section at the top of each of the scripts.

Download

The programs:

Documentation:

• mtpt documentation and changes
• loadmtpt documentation and changes
• cleanmtpts documentation and changes

License

Copyright 1999, 2000, 2003, 2004 The Board of Trustees of the Leland Stanford Junior University.

These programs are free software; you may redistribute them and/or modify them under the same terms as Perl itself. This means that you may choose between the two licenses that Perl is released under: the GNU GPL and the Artistic License. Please see your Perl distribution for the details and copies of the licenses.