[OpenAFS-devel] Solaris 10 predicament update

[Jeffrey Hutzelman]

On Saturday, September 08, 2007 07:46:54 PM -0400 Dale Ghent 
<daleg@umbc.edu> wrote:

> 2) Option 2 would be to use the above mentioned ioctl-based method,  but
> to remove it entirely from the critical code path. We could, at
> AFSinit() time, create a worker thread which would periodically  update a
> global struct of interface telemetry. The worker thread  would wake up
> every, say, 30 seconds (tunable), lock the struct via  mutex, update it,
> unlock, and return to sleep. The RX and  ServerPredfs code can read their
> desired values from this struct when  they need it, spinning if need be.

This doesn't seem unreasonable.



> 4) We toss caution to the wind and let modern routers deal with UDP
> frags the way they should be and dispense with the UDP packet size
> adjustments based on MTU, or at least nail them to 1500. If you're  still
> using AFS over a PPP connection... well... sorry 'bout that. We  also let
> the kernel routing table do its job and dispense with  selecting
> interfaces. I don't think even the NFS code jumps through  these kinds of
> hoops. Is there a reason we should be? I admit I'm not  too familiar with
> the inner details and history of things here, so  feel free to gently
> clue me in.

This is a horrible idea.  Fragmentation of a large IP datagram increases 
both the likelyhood that it will be lost and the amount of data that must 
be retransmitted if it is, as opposed to use of a PMTU-sized datagram. 
This means that if the network is congested, packet loss will lead to more 
retransmits and more packet loss, making the problem worse.  It is 
essential that any protocol carrying a signficant amount of traffic 
discover and follow the path MTU.  Discovering the local interface MTU is a 
critical part of this process, since sending a larger-than-MTU packet will 
result in local fragmentation, which has all the problems I just described 
and prevents discovery of the true path MTU.


>
> 5) Continue to use the ILL method and release OpenAFS 1.4.5 with the
> code being compatible with s10u4. We simply tell people that if you  want
> to run OpenAFS client version 1.4.5 or greater, you also need to  run
> Solaris KU 120012-14 (x86) or whatever the analog is if you're  running
> SPARC.

No.  A flag day which forces people to upgrade AFS and Solaris at the same 
time is unacceptable.  It must be possible to upgrade one or the other 
first.  If at all possible, it should be possible to have a single kernel 
module which either determines at runtime which technique to use or always 
uses a technique that works on both old and new Solaris.  Lacking that, the 
next best thing is to build two modules and have the startup scripts decide 
which to load, or perhaps which to install.

Incidentally, having two platforms (sun4x_510 and sun4x_510u4) is nearly as 
bad as requiring AFS and Solaris to be updated at the same time.  Many 
people will not understand that these differ only in a single file, or why.


> 6) Any other idears?

Find the interfaces we need, and get someone within Sun to help us either 
get a contract on them or get them reclassified.

-- Jeff