[2283] in SIPB-AFS-requests

home help back first fref pref prev next nref lref last post

Re: balance, afsmaint locker

daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Fri Feb 2 09:20:10 1996

From: mhpower@MIT.EDU
Date: Fri, 2 Feb 1996 09:17:08 -0500
To: ghudson@MIT.EDU
Cc: sipb-afsreq@MIT.EDU

>two of our partitions have, once again, hit more than 90% full, ...
>                                                      ... No one else
>seems to notice or correct these situations, and I'm tired of doing it
>by hand.

I often notice these, but don't do anything about it since I don't
generally believe I have enough information about the performance
or stability of the more empty disks. Over the past year or so,
there've been a number of occasions where people have reached
conclusions about certain disks being unsuitable for new volumes,
but haven't made specific suggestions via mail (e.g., "avoid using
ronald-ann:/vicepj unless you really know what's going on with these
timing data / error patterns"). This makes it more difficult to know
when a volume move might interfere with someone else's plans.

>First question: do people have objections to using the CMU "balance"

I think this would be fine, as long as the configuration file is kept
up-to-date with information on what disks/partitions shouldn't be
used. I believe partitions can be prevented from receiving new volumes
using '<' lines in the configuration file.

>Second question: I'd like to see an "afsmaint" locker containing:

Personally I would use /afs/sipb/service/afs/{bin,notes} since I don't
feel it's really the responsibility of the athena-cell maintainers to
notify sipb about changes they make to software that they rely on. If
they actually happen to want a shared afsmaint locker, though, I
suppose it would be ok.

>	* Information about known problems with AFS, such as:

In the past, often the "known problems with AFS" have been security
problems such as localauth vulnerabilities, lack of read protection on
private pts entries, and unchecked setgid/setuid file creation. I
think it's unlikely that this information could be maintained in a
shared locker, although again it's probably up to the athena-cell
maintainers to decide if this is what they'd like to do.

Matt

home help back first fref pref prev next nref lref last post