[OpenAFS] AFS Mount Points, Nomenclature

[Esther Filderman]

On Fri, Aug 7, 2009 at 1:15 AM, beelz<skyliner306@yahoo.com> wrote:
>
> Would someone explain the relationship of /afs and /vicepX to standard mo=
unt
> points that one sets up during a BSD or Linux install? =A0I'm new to AFS =
and
> I'm trying to determine how to partition my 1TB hard drive to give a larg=
e
> amount (approx 990 gb) to shared AFS space. =A0I do not plan to use addit=
ional
> servers or drives in the near future. =A0This is more of an experimental
> learning environment. =A0I am inclined to mount /vicepa as the large part=
ition
> based on what I've read, but I would appreciate any analogies or
> explanations experienced users could offer to help me understand the "rea=
l"
> versus "virtual" directory structures which AFS appears to employ.

The first thing you need to remember is that AFS is a client-server
architecture system.  While you can run both on one machine, the
concept of "files on the server" and "files on the client" are
distinct.

Your "vice" partitions (the name is left over from the very early
days) are where files are stored the server, and what the fileserver
talks to for serving and storing files.  /vicepX  is a plain directory
created with plain old mkdir.  You can run just about any filesystem
underneath /vicepa as long as it's not something weird like ReiserFS
(ie. no allocate-inodes-on-the-fly FS).   When you look in the /vicepX
director{y,ies} of a running in-use AFS server you will see files only
a few K in size. These are the volumes you create and use, and you
cannot examine their contents trivially without an AFS client (or
related tool).

Creating one huge partition is not necessarily a bad thing, especially
if you are just experimenting. Do not, however, use very huge volumes
unless the data inside is all related.  The potential administration
issues -- related to backup & restore, RO clones and volume moves --
likely won't be much of an issue with a single test machine, but it's
just a Bad Practice to get into.

/afs is created on the client when the AFS client process (afsd) is
started.   It shows up under df as a mount point, usually of some
inordinately huge size that relates nothing to the size of disk space
on your server.  It's simply the gateway to your volumes.

afsd will also create a cache, a staging place for files going in and
out of the client. You set the size on setup; I forget the default,
it's probably still absurdly small.  The cache stores chunks of files
(not whole files, so if a part is corrupted only that little part has
to be resent) so you don't (usually) have to worry about "the cache is
smaller than my file". [ The cache is smaller than my file" can be a
problem if all your files are bigger than your cache (because you're
constantly throwing things in & out),]  Cache size and settings is a
black art I won't get into here.  A default (set in the "cacheinfo"
file) of 300-400M is probably a good start.

In your case I would think about what you plan on storing -- just some
test files?  Your mp3 collection?  Triple the size of what you plan on
storing for a test.  Note that with only one machine you may not be
able to simply resize your /vicep* partition (but if not there are
hoops you can jump through, including abusing vos dump/restore).   Is
the 1T disk in addition to your system disk?  If so, if you have
enough space for the cache on your system disk, I'd just make it all a
couple of /vicep* partitions (more than one can let you play with
things like volume moves.)  Best practice is to make the cache it's
own partition, but if you can't, you can't. Just make sure it won't
fill your system disk up if it fills.

Note that this is a glossy overview, and now the nitpickers will come
out.  I love the nitpickers to death (ok, most of them), don't let the
information overwhelm you.  Remember to do backups. Worst thing that
happens is you screw up & have to start again.  In which case, save
your KeyFile -- someplace *safe*.

Good luck,
Moose