On Tue, Feb 17, 2009 at 7:19 PM, Michael Schuster <Michael.Schuster at sun.com> wrote: > I've gone through what I gathered of the threads on this subject and will > try to summarise, so we can try to (finally) reach an agreement. In the > effort to get a complete picture, some of you may have seen some of this > before, sorry about that. ... > > c) some entity (probably ilbd, but this would need to be discussed > seperately) creates a mapping from IPv6 addresses to a string value that > fits into 30 characters. This string then serves as the "name" of the > respective backend server and the string representation of the IPv6 address > is stored as data in the kstat. This approach also has several drawbacks: > - a user running kstat(1m) (instead of "ilbadm show-statistics") may > find it difficult to find out which server a set of stats is actually > talking about. > - the mapping has to be easily reversible (that may not be a problem if > the complete IPv6 address is a kstat data element - needs to be examined). > > One advantage of this, as I understand it, is that the current kernel code > already is built to support it. > > d) Peter Tribble suggested something about a name-value pair (ie > KSTAT_TYPE_NAMED, though I have yet to understand how this would enable us > to use the aforementioned 39-character strings as names (ie keys) - the > names for KSTAT_TYPE_NAMED is also limited to the infamous 30 characters.
I believe that my suggestion is a variant of (c). The point being that you make sure that the IPv6 address is available as one of the kstat data values. As for the cheating, I don't like it. As a kstat consumer, I then have to write code to work out whether we've cheated or not and handle both cases. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
