[2596] in SIPB-AFS-requests
Re: New AFS server status
daemon@ATHENA.MIT.EDU (John Hawkinson)
Sat Dec 28 19:32:18 1996
Date: Sat, 28 Dec 1996 19:31:36 -0500
To: Greg Hudson <ghudson@MIT.EDU>
Cc: sipb-afsreq@MIT.EDU
In-Reply-To: "[2595] in SIPB-AFS-requests"
From: John Hawkinson <jhawk@MIT.EDU>
> * jhawk has suggested that it might be nice if we could go to
> Solaris for AFS service. There might be certain advantages
> to this approach (being able to leverage off mkserv), but I
> think we should wait for ops to do it first. (In
> particular, I don't think we want to be building our own set
> of AFS server binaries.) So I'm going
[Greg meant to say "...ignore that advice" at the end]
I just wanted to clarify my reasoning here (it may or may not
be relevent to afs as a service).
I've finally reached the opinion that SunOS is a dead operating
system. IMHO, there a number of features an operating system should
have if you're going to use it, and you should not install operating
systems without them. In the case of SunOS, the major pertinent
ones are:
multicast
decent packet capture
default TCP buffer sizes
default TCP mss
enabling udp checksums
(give up on Path MTU Discovery)
These are not immensely relevent to AFS (except for udp checksums),
but you might imagine packet capture would be nice to have for some
kinds of diagnostic purposes, and the multicast might be if people
were doing odd filesystem research, or ended up writing some
applications that ran on AFS servers (for monitoring or management or
what-have-you) that used multicast (or something).
None of these are not a colossal pain to do under SunOS, but require
applying kernel patches (ipmulti 3.5 and bpf). I think any SunOS
system anyone installs these days should apply them. The TCP fixes
are pretty much patches to /sys/netinet/in_proto.c. You could look at
/afs/sipb/project/kernel/sunos.413U1/inproto.mods, though these apply
equally to 4.1.4 as to 4.1.3U1.
It's not clear to me that Ops is going to move away from SunOS as a
platform in the near future. I think that we ought to move sooner
rather than later.
Our dependance on using Ops binaries has always struck me as kind of
wrong. If we cannot use stock transarc binaries, we should consider
doing our own builds, with clear documentation on what changed
from the transarc "release" and why it was necesssary.
--jhawk
