On Saturday, September 08, 2007 07:46:54 PM -0400 Dale Ghent <[EMAIL PROTECTED]> 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
