[2280] in SIPB-AFS-requests
balance, afsmaint locker
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Feb 1 11:09:38 1996
Date: Thu, 1 Feb 1996 11:07:51 -0500
From: Greg Hudson <ghudson@MIT.EDU>
To: sipb-afsreq@MIT.EDU
Cc: ops@MIT.EDU
[ops is cc'd because they may be interested in the idea of an afsmaint
locker.]
While moving data off of ronald-ann's 4GB Seagate disk, I noticed that
two of our partitions have, once again, hit more than 90% full, even
though the cell itself is only about 75% full (without the extra 4GB
of space forthcoming when the Seagate disk is replaced). No one else
seems to notice or correct these situations, and I'm tired of doing it
by hand.
First question: do people have objections to using the CMU "balance"
program to balance out partition usage? I wouldn't feel comfortable
running it automatically on a regular basis, but it would be
convenient to be able to run it by hand instead of arbitrarily finding
volumes to move. balance takes into account average volume size as
well as number of volumes, and can be made to take into acount number
of accesses in the past week (but that relies on a server patch we
don't have). Right now, balance spews out 373 vos move commands when
it looks at the sipb cell, but presumably that would go way down after
the first run.
Second question: I'd like to see an "afsmaint" locker containing:
* Tools such as:
- balance
- bert's volmove script
[Off-topic note: bert's volmove script needs work with
regards to replicated volumes. Unfortunately, no automated
program can do a perfect job of moving replicated volumes
without being given a third, temporary area.]
* Information about known problems with AFS, such as:
- The vos move bug
- The vos release bug (creating volumes no the root)
- bosserver not dissociating itself from its
controlling tty and dying
There are two ways to go about creating such a locker:
* SIPB could have its own version and ops could do whatever it
wants. This would be the best option if various ops AFS
maintainers don't want to use software in a locker writable
by SIPB AFS maintainers, or vice versa.
* We could make it writable by both SIPB and ops AFS
maintainers, with the understanding that software changes
have to be announced in advance. The idea here would be
that the information area could be contributed to both by
ops staff and SIPB people (who uncovered all three of the
failure modes I gave as examples).
