On Mon, 1 Aug 2011 14:05:33 -0700
Tom Maher <tma...@watson.org> wrote:
> Is the vlserver DB format documented anywhere?
I don't think so. At least, I don't think the current form of storing
fileserver addresses is documented in any clear fashion; the old formats
might be, but they're not as useful.
If anyone wants to look at it, some basics: in the data for each vldb
entry, the "server" is represented by a "server number", which is an
index into a global table called 'hostaddress' in the in-memory
representation, and 'IpMappedAddr' in the structures for the on-disk
representation. That global table is just an array of 4-byte integers,
and historically that was the IPv4 address for the server. There are
only 256 entries in the table, which is the cause for the per-cell
fileserver limit in AFS.
A modern extension to the database is to allow fileservers to have more
than one IP in the database. So, instead of hostaddress[X] being an IP
address, if the first byte of hostaddress[X] if 0xff, it's treated as a
special multihomed entry. The second byte is the 'base' of the entry
(indicating with MH block we look at), and the last 2 bytes are the
'index' (indicating which entry in the MH block to look at). An "MH
block" is just a structure used to allocate several addresses at once,
so we can allocate in chunks, but we don't need to allocate all possible
MH structures all the time. The first MH block is pointed to by the SIT
member in the vldb header structure ('struct vlheader'), iirc.
Anyway, the 'struct extentaddr' structure is the current modern
structure used for storing addresses, which is in
src/vlserver/vlserver.p.h. Looking at the FindExtentBlock function in
vlutils.c I think helps understand the MH structures a bit, though that
doesn't really deal with the on-disk layout. For that, the readExtents
function may help, since it basically converts the on-disk MH format to
the in-memory ones.
Each MH block has a 'flags' field, so this may involve just defining a
new 'type' of MH block (aside from the 'header' and 'continuation' ones
right now), which may be able to be of any size and layout that we want
(except for the 'flags' field which needs to be in the same position).
Or it may be more complicated than that; I don't think too much thought
has been put into the details of this yet, since, while it is important,
it is one of the later steps of getting IPv6 to be useful, since the
lower levels like Rx need to work first.
--
Andrew Deason
adea...@sinenomine.net
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
