We have sun4m_53 client machines around here, and I know a lot of
work has been put into making these machines work reliably with AFS.
If it's an AFS client, unless it has a *very* recent copy of AFS,
I would not be at all surprised by crashes.
The only thing ChangeAddress does is change the address in the VL database.
Ie, all it's doing is writing one record in one database on the file servers,
a perfectly safe operation. It doesn't do anything to the local machine.
It shouldn't be directly capable of crashing anything. Indirectly,
well, hmm...... In looking through things, I would have to say that there
are some remarkably ugly things associated with this ChangeAddress thing.
I'd be *very* careful what I did with it.
In the 3.3 VL database, there is a list of IP addresses for file servers.
Basically, the VL server "knows" every possible file server, by address.
There is, apparently, no way to delete a file server, short
of rebuilding the entire database. There's probably a way to
do this, perhaps with "vlclient", although it's undoubtedly easiest
to just start over and use "syncserv". The change address function
just changes the address. It doesn't check to see if the new
address is already present. It's not clear to me what the ramnifications
of having 2 entries the same in VL's list of file server
addresses are, but I suspect they're not good.
The reason "vos listvol" "worked" for you is, it goes against
the actual file server, not VL. Since you had the old hostname
pointed against the new server, the new server responded, and
listed the appropriate volumes. That, at least, is reasonable.
At a shear guess, I think that "backup addhost" and "backup delhost"
will do a fine job in getting rid of the backup system's notion
of the old file server. Caveat: I spend little time with the
backup code.
-Marcus Watts
UM ITD RS Umich Systems Group
