On Thu, 25 Oct 2007, Harald Barth wrote:
If different database server versions would generate pain, I would had to do something about the following a long time ago... $ /usr/openafs/sbin/rxdebug anna 7003 -v Trying 130.237.232.112 (port 7003): AFS version: OpenAFS 1.4.0 built 2005-11-15 $ /usr/openafs/sbin/rxdebug hokkigai 7003 -v Trying 130.237.232.114 (port 7003): AFS version: OpenAFS 1.2.11 built 2004-01-12 $ /usr/openafs/sbin/rxdebug crab 7003 -v Trying 130.237.232.29 (port 7003): AFS version: OpenAFS 1.4.2 built 2006-11-09
Very interesting.
I vaguely remember a "take everything down" scenario necessary many many years ago.
Yeah, I remember that, too. I think it was something like IBM AFS 3.4 --> 3.5. It was because of a database format change, IIRC. So this suggests we don't need to worry too much about our database servers, just do them whenever is convenient. Which leads into a different question: Is there any reason not to start off by upgrading one or more of our fileservers from 1.2.13 to 1.4.4, while leaving the database servers at 1.2.13 until sometime later? For completeness I should state that the prime motivation here is to get to a point where our Windows users can begin taking advantage of file locking. (Obviously their client binaries need to be up to date, too.) -Mitch _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
