Juha Jäykkä wrote:
Hmm, so somehow it cached the location of the volume.
I wonder if a "fs checkvolumes" would have helped.
I'm not very experienced on afs, but I'm not *that* beginner either. =) I
tried that, it simply complained that it could not contact the server at
the old address. I'm not sure if it contacted the server at the new
address, though.
It seemed to me as if openafs servers thought there are two distinct
servers: the one with the old ip and the one with the new. It never
Yes, to remove the old server from the vldb entirely you should do a
"vos changeaddr -oldaddr <original IP address> -remove".
The former commands just removed the entries of the volumes on the old
server.
seemed to occur to openafs that they were indeed the same server. (Would
it even be possible? I mean, how could it tell?) The problem was that
openafs thought the volumes were at the old ip and even though the fs
instance at the new ip had attached the very same volumes, they were not
visible. That's not true: the RO replicas at the new ip *were* indeed
visible, but the RW's were not. Only, after vos delentry, all the old
ones were (naturally) removed from the vldb, but *still* those same
volumes from the new ip stayed inaccessible *to this one client*, which,
by the way, happened to be running at machine which had just got a new
ip. Perhaps that had something to do with it?
Just a guess: the new location of the volume is told the client via a
callback. If that's the case and went wrong, then you should find
something about CallBack failed for the old client-address in the
server-logs. But I'm not sure how the client are notified exactly.
/Christof
-Juha
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
