> Unfortunately, you can't get 'vos listvldb' to directly show you server > UUID's or more than one address per server. However, any given address can > only be assigned to one server, so you can take the server names or > addresses reported by 'vos listvldb' and feed them to 'vos listaddrs' to > find out the UUID and/or other addresses assigned to that server. >
Makes sense. Is an extension of listvldb a possibility? (For consistency, deprecating the old RPCs.) > > If I remember correctly, buserver sends an address. One address. It > > seems like a small performance gain, though. butc could be doing the > > VLDB lookups in all passes. > > I suspect that's not so much an attempt at improving performance as an > indication of how old the bu subsystem is and how little attention it got. > Oh... Well I live on the hopes my new employer is willing to give me some OpenAFS-time... So, now my question is... Is buserver in use? Do people use tapes or can it be safely converted to file based storage? > > I'm not sure if the clients are better off making the decision, > > though. If they are behind NAT with the same subnet as the server, > > things will get messy. The idea of using common address bits means > > it will resort to global address space pretty easily. However, it's > > a hack, yes. > > Well, it's got to resort to a global address if it's not on the same > private network as the server. However, since the vlserver never gets to > see the client's private address, it's not really in a position to make the > right decision. > The Thesis: The address which the server sees, is in the same subnet the server is on, as seen from the client. Tommie Gannert _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
