AFS is a distributed filesystem that enables co-operating hosts (clients and servers) to efficiently share filesystem resources across both local area and wide area networks. Perhaps the best place to start reading is Transarc's own AFS home page, which contains a general FAQ. This can answer a few other questions that you might be tempted to post on the listserv.
Yes! The AFS client has been ported to Linux running on Intel platforms. Currently both 1.2 and 2.0 (2.0.4 and higher) kernels are supported, along as you use the modules-2.0.0 utilites. SMP Support became possible with kernel 2.0.32. Ports for Alpha machines, Sparcs, as well as a port of the AFS server, may be available in the near future.
The Linux-AFS mailing list is a forum for discussing issues specific to the Linux AFS port, getting setup help, reporting bugs, etc. To join the mailing list, send an email message with: "subscribe linux-afs" to linux-afs-request@mit.edu.
If you are at MIT, you can add yourself to the linux-afs mailing list with:
blanche linux-afs -a $USER
To submit messages to the list, send email to linux-afs@mit.edu. To unsubscribe, send a message with: "unsubscribe linux-afs" to the linux-afs-request@mit.edu address given above. Don't send subscribtion or administrative requests to the Linux-AFS mailing list. (It's bad nettiquite)
Yes! Go here!
Slow down and read 2.3 again. We are not going to repeat it.
Basically, it's free as long as you are affiliated with an organization with a license for the AFS server (if you're not, the client won't do you any good anyway).
Michael Krasnicki asked about Arla. In my experience Arla is quite stable with 2.2 kernels, although the included tools (klog, unlog, tokens) do not work as well as Transarc's.
Magnus Ahltorp of Arla writes:
Please note that the linux arla development is mainly directed towards 2.1 kernels. If anyone wants to do some 2.0 support, fine with me, but I will not put much effort into it.
MR-AFS is "Multiple Residence - AFS". It was developed at Pittsburgh Supercomputer Center (PSC) as a distributed hierachical storage system. It allows for data migration to servers with any kind of HSM system such as Cray/SGI's DMF or IBM's ADSM or LSC's SAMFS or Unitree or whatever. Our site for instance has 7 Tbyte of data in AFS, but only about 600 Gbyte of disk space. Most data (not most files) are stored in roboted tape libraries through DMF on SGI Origin 2000 systems.
MR-AFS is based on Transarc's AFS server code, but files in a volume are not necessarily stored in the vice-partition where the metadata (volume-header, vol-info-file, small- and large-vnode-files) are stored, but may be instead be stored in any shared residency. These shared residencies are disk partitions on the same or other servers. A ubik-database knows about the state of all (up to 31) shared residencies and the fileserver and a auxiliary process called "scanner" decide based on the information in the database where files have to go or what copies have to be created or deleted.
In order to be independent from the inode-format of the underlying unix system which may be different for HSM systems PSC decided to not necessarily use the AFS-inode interface as in standard AFS, but to allow for standard Unix filesystems. In this case the files are identified by their AFS-Fid and named accordingly. They are distributed equally by a hash code over two levels of directories in the partition. This technique, of course, is slightly slower than the AFS-inode interface because of the additional directory lookups, but it is much more transparent and - as said above - completely independent on the type of the filesystem.
In order to allow for remote access to shared residencies the real I/O has been put into a separate software layer which in the case of local accesses is called by a simple subroutine call, but for remote access by rx-type RPCs. On the remote server runs a small daemon "remioserver" which executes these RPCs.
The authors of MR-AFS Jonathan Goldick, Bill Zumach, Chris Kirby left PSC some years ago. Our site being the biggest user of MR-AFS therefore decided to do maintenance and development ourself. There are some other sites in Germany and the US which get the code from us. To use MR-AFS, however, you need an AFS-source license from Transarc and additionally a license from PSC which generally is granted for free.
To come back to the LINUX case: even if you did not implement the AFS-inode part of the AFS system call we were able to build fileservers using the UFS-interface. This was more for academic interest or because I had to compile all the stuff abyway in order to allow on LINUX for the additional commands to handle migrated files. Even if the fileserver turned out to be rather fast (faster than on Solaris 2.5 on Ultras, and only slightly slower than on AIX 4.1 on Power2 machines with SSA-disks) I wouldn't recommand using LINUX as a fileserver. As much as I know there are still limitations in the size of the partitions and it is not a journaled filesystem. Also, sites which have enough money to buy an AFS source- and site-license generally don't need to use LINUX boxes as fileservers.