[1764] in SIPB-AFS-requests
Disks
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Wed Feb 1 18:43:40 1995
From: ghudson@MIT.EDU
Date: Wed, 1 Feb 1995 18:43:30 -0500
To: usenet@MIT.EDU, sipb-afsreq@MIT.EDU
We received the two 4GB disks for news today, which I placed on opus.
I also disconnected the external 1GB disk from rosebud and placed it
on opus. We now have 1GB disks on SCSI IDs 0 and 1 of opus, and 4GB
disks on SCSI IDs 2 and 5, for a total of 10GB of external disk. The
internal disk has SCSI ID 3. Currently, no external disks are mounted
on opus. I am currently testing the disks and will partition them
when I'm done.
R Squared shipped us device-to-machine cables, even though I (twice)
asked for device-to-device cables. Fortunately, I had gotten a couple
of device-to-device cables from John Chase a couple of months ago when
we were having trouble with the micropolis disk.
(sipb-afsreq people can hit 'D' now.)
Since this is how much disk we plan to have on opus in production, we
should be ready to do a cutover once we decide how to put hierarchies
on the partitions. Matt wrote in [31962] in usenet:
> One thing that definitely has to be done in advance is deciding
> which files from bed's /news/spool{,2,3} will be copied to which
> disks. I think one configuration that should work fairly well is to
> have two spool partitions for article files on each of the two 4 Gb
> disks, and have one partition for the .overview files on a 1 Gb
> disk. It might be nice to have a second 1 Gb disk solely for the
> history database, although that seems a bit extravagant.
I wrote in response, in [31965]:
> I think of it more as filtering by type; I don't think usenet is a
> good method for distributing binaries. I would, in fact, advocate
> lowering the expire time on comp.binaries as well (but leaving the
> max expire time at 28 days so that the postings of uuencode et
> al. stay there).
> I'd say a default *.binaries expire time of 50% of the normal expire
> time is reasonable.
I've since discovered that alt.binaries is much bigger than I thought
it was (apparently about 200MB per day), and that comp.binaries is
much smaller than I thought it was. Based on a Zephyr conversation I
had a few days ago, virtuall every SIPB member except me is opposed to
eliminating alt.binaries.* altogether, but most people feel it's okay
to have a very low expire time on it. So I think an expire time on
alt.binaries of much lower than on the other hierarchies (one or two
days) is warranted.
(For those who may be interested, my reasons for wanting not to carry
alt.binaries.* are that (a) it's extremely high-traffic, and (b) it is
used for large amounts of data which does not inherently expire, and
therefore doesn't fit into the Usenet model or scale the way most of
Usenet does. FTP would be a more efficient means of distribution.
Most people opposed removing alt.binaries.* because there is currently
no other way to get at the information contained therein, or because
it would be perceived as censorship.)
SunOS, in its infinite wisdom, chose these disk assignments:
Disk SCSI ID Type
---- ------- ----
sd0 3 Internal 1GB
sd1 1 External 1GB
sd2 2 External 4GB
sd3 0 External 1GB
sd16 5 External 4GB
I would suggest that our partitions be:
/dev/sd0a 7.5MB Root
/dev/sd0d 15MB AFS cache
/dev/sd0g 750MB /usr
/dev/sd1c 1GB /news/over
/dev/sd2d 2GB /news/spool
/dev/sd2e 2GB /news/spool2
/dev/sd3c 1GB /news/spool3
/dev/sd16d 2GB /news/spool4
/dev/sd16e 2GB /news/spool5
I will try to figure out what layout of news hierarchies we want on
the new partitions based on the current sizes on bed.
