Import Upstream version 1.8.5
[hcoop/debian/openafs.git] / doc / txt / vldb.txt
CommitLineData
805e021f
CE
1
2This document describes version 4 of the OpenAFS Volume Location Database
3(VLDB) file format.
4
5
6VLDB file layout
7
8The vldb.DB0 file consists of 64 octet ubik header, followed by a 132,120 octet
9vldb header, followed a variable number of vldb records. Records are either a
10148 octet volume location (vl) entry or a 8192 octet multi-homed (mh) extension
11block. A bit flag at a fixed offset of each record specifies the record type.
12A field in the vldb header indicates the location of the last record. Any data
13in the file following the last record is ignored.
14
15
16Ubik header
17
18The vldb.DB0 file begins with a 64 octet ubik header. All fields are in
19network byte order. Only the first 16 octets of the ubik header are used. The
20unused fields should always be zero. The first 16 octets of the ubik header
21contain the representation of a struct ubik_hdr, with all the fields in network
22byte order:
23
24 0 1 2 3
25 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
26 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
27 | ubik_magic |
28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
29 | padding | header_size |
30 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31 | epoch |
32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
33 | counter |
34 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
35 | [unused] |
36 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
37 | [unused] |
38 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
39 | [unused] |
40 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
41 | [unused] |
42 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
43 | [unused] |
44 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
45 | [unused] |
46 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
47 | [unused] |
48 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
49 | [unused] |
50 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
51 | [unused] |
52 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
53 | [unused] |
54 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
55 | [unused] |
56 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
57 | [unused] |
58 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
59 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
60 0 1 2 3
61
62magic is the ubik file identification. It should always be 0x00354545.
63
64pad1 is unused, should always be 0
65
66header_size is the size of the ubik header (including unused space), should always
67be 0x40
68
69epoch is the ubik quorum epoch value.
70
71counter is the ubik counter for transactions and updates.
72
73unused space should always be zero.
74
75
76The ubik header is not exposed through the VL_ RPC package, and as such is not
77considered to be part of the logical VLDB database.
78
79Subsequent discussion will refer to VLDB addresses, or simply addresses. A
80VLDB address is a logical offset to a data within the VLDB. The physical file
81offset of data referenced by a VLDB address is the VLDB address plus the size
82of the ubik header (64 octets).
83
84
85VLDB header
86
87The VLDB header follows the ubik_header. It is the logical beginning of the
88VLDB. The VLDB header is 132120 octets in size. The majority of this space
89contains four hash tables enabling quick lookups of volumes by name and id.
90All integer fields are stored in network byte order.
91
92The layout of the VLDB header is:
93
94 0 1 2 3
95 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
96octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
97 0 | version |
98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
99 4 | headersize |
100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
101 8 | freePtr |
102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
103 12 | eofPtr |
104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
105 16 | allocs |
106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
107 20 | frees |
108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
109 24 | MaxVolumeId |
110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
111 28 | TotalEntries[0] (rw) |
112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
113 32 | TotalEntries[1] (ro) |
114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
115 36 | TotalEntries[2] (bk) |
116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
117 40 | IpMappedAddr |
118 ~ ... ~
119 1056 | |
120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
121 1060 | VolnameHash |
122 ~ ... ~
123 33820 | |
124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
125 33824 | VolidHash[0] (rw) |
126 ~ ... ~
127 | |
128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
129 | VolidHash[1] (ro) |
130 ~ ... ~
131 | |
132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
133 | VolidHash[2] (bk) |
134 ~ ... ~
135132112 | |
136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
137132116 | SIT |
138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
139 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
140 0 1 2 3
141
142vldbversion is the vldb disk format version number. This document describes
143version 4.
144
145 Note: The OpenAFS vlserver creates empty vldb files as version 3, and
146 converts the vldb to version 4 in place the first time a fileserver
147 UUID is registered.
148
149headersize is the size in octets of the vldb header, currently 0x020418 (132120)
150
151freePtr is the logical address in octets of the first in a linked list of
152unused vldb entries in the vldb database file (that is the first logical hole
153in the database file). This value is zero if the database is densely packed.
154The physical file offset to the first free entry is the freePtr value plus the
155size of the ubik header (64 octets). Every free vl entry in the vldb should be
156on the free list. The nextIdHash[0] vl entry field holds the address of the
157next vl entry on the free list.
158
159eofPtr is the logical address in octets of the end of the database file. When a
160new entry is created that extends the database file, it will be created at this
161logical index.The physical file offset to the end of the database file eofPtr
162value plus the size of the ubik header (64 octets).
163
164allocs is the number of calls to AllocBlock(), for statistical purposes.
165
166frees is the number of calls to FreeBlock(), for statistical purposes.
167
168MaxVolumeId is the largest volume id allocated. It is incremented every time
169a volume is created.
170
171TotalEntries[0] is the number of read-write volume entries.
172
173TotalEntries[1] is the number of read/only volume entries.
174
175TotalEntries[2] is the number of backup volume entries.
176
177IpMappedAddr maps vl entry serverNumbers to file server information. The vl
178entry serverNumber field is used as an offset into the IpMappedAddr table. The
179IpMappedaddr is a table of 255 records, one for each possible serverNumber,
180from 0 to 254. Each record is a 32 bit integer in network byte order. Empty
181records should be zero filled.
182
183IpMappedAddr records hold either a reference to a mh entry or a single IPv4
184address. Records which contain 0xFF in the first octet are references to mh
185entries. Non-zero records which do not contain 0xFF in the first octet hold a
186single IPv4 address in network byte order.
187
188The format of a reference to a mh entry is:
189
190 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
192 | 0xFF | base | index |
193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
194
1950xFF in the first octet indicates the record contains a multi-homed entry
196reference, instead of an IPv4 address.
197
198base is the mh extension block number; supported range is 0 to 3.
199
200index is the index to the mh entry within the mh extension block; supported range
201is 1 to 63. (Index of 0 is reserved for the mh extension block header.)
202
203Following the index are four hash tables, each containing 8191 (a prime number)
20432-bit entries in network byte order. Each entry represents a hash bucket and
205holds the address of the vl entry at the head of the hash chain, or zero to
206indicate an empty hash bucket. Every vl entry which is not free should be in
207all four hashes.
208
209VolnameHash is the hash table for searches by volume name. The nextNameHash
210field at the head of the chain holds the address of the next vl entry in the
211hash chain.
212
213The NameHash hash function is targetted for ASCII text and is similar to the
214PRDB name hash function. Each octet of the volume name is treated as an
215unsigned integer from which 63 (decimal) is subtracted, and the resulting
216stream of integers is used as the coefficients of a power series with base 63
217(decimal), with the least significant coefficient appearing first.
218
219For example, for a volume name string string of "abc", which is the stream
220of octets (in decimal):
221
222 97 98 99
223
224then the power series used in the hash function calculation would be
225(all numbers in decimal):
226
227 34 + (35 * 63) + (36 * 63**2)
228
229The value of this power series is stored in an unsigned 32-bit integer, and as
230such is implicitly computed modulo 2**32. The remainder modulo 8191 (the size
231of the hash table) of this 32-bit value is used as the index into the hash
232table for this name entry. (This hash function can be easily implemented
233iteratively.)
234
235
236VolidHash[0] is the hash table for searches by read-write volume ID. The
237nextIdHash[0] field at the head of the chain holds the address of the next vl
238entry in the hash chain.
239
240VolidHash[1] is the read-only volume ID to vldb entry hash table. The
241nextIdHash[1] field at the head of the chain holds the address of the next vl
242entry in the hash chain.
243
244VolidHash[2] is the backup volume ID to vldb entry hash table. The
245nextIdHash[2] field at the head of the chain holds the address of the next vl
246entry in the hash chain.
247
248The VolidHash hash function the remainder modulo 8191 (the size of the hash
249table) of the absolute value of the volume id.
250
251
252SIT holds the logical address of the first multi-homed extension block in the
253vldb. Each multi-homed extension block holds 4 logical addresses to additional
254multi-homed extension blocks.
255
256
257VLDB Records
258
259VLDB Records follow immediately after the VLDB header. Each record is either a
260148 octet sized volume location (vl) entry or a 8192 octet sized multi-homed
261(mh) extension block. A bit flag at a fixed offset specifies the record type.
262
263 Note: The mh extension block size is *not* a multiple of the
264 vl entry size.
265
266The only invariant field is the single bit field which indicates the
267record type:
268
269 0 1 2 3
270 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
271octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
272 0 | [record-specific] |
273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
274 | [record-specific] |
275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
276 | [record-specific] |
277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
278 12 | [record-specific-flags] |C| ... |
279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
280 | [record-specific] |
281 ~ ... ~
282 | |
283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
284
285C is the continuation block flag (VLCONTBLOCK). A value of 0 indicates the
286record is a 148 octet vl entry. A value of 1 indicates the record is a 8192
287octet mh extension block.
288
289
290VL Entry
291
292The 148 octet vl entry maps a volume group to a set of file server locations
293for each volume in the volume group. A volume group consists of a single
294read-write volume, zero or one backup volumes, zero or more read-only volumes,
295and zero or one temporary clone volumes.
296
297The vl entry also holds information for volume administration.
298
299All integer fields are in network byte order.
300
301The layout of the vl entry is:
302
303 0 1 2 3
304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
305octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
306 0 | volumeId[0] (rw) |
307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
308 | volumeId[1] (ro) |
309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
310 | volumeId[2] (bk) |
311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
312 12 | flags |
313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
314 | LockAfsId |
315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
316 | LockAfsTimestamp |
317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
318 | cloneId |
319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
320 | nextIdHash[0] (rw)/(free) |
321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
322 | nextIdHash[1] (ro) |
323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
324 | nextIdHash[2] (bk) |
325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
326 40 | nextNameHash |
327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
328 44 | name |
329 + +
330 | |
331 ~ ... ~
332 | |
333 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
334 108 | | serverNumber table |
335 +-+-+-+-+-+-+-+-+ +
336 112 | |
337 + +
338 | |
339 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
340 120 | | |
341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
342 124 | serverPartition table |
343 + +
344 | |
345 + +-+-+-+-+-+-+-+-+
346 132 | | |
347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
348 136 | serverFlags table |
349 + +
350 | |
351 + +
352 144 | |
353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
354 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
355
356
357volumeId[0] is the volume id allocated for the read-write volume in this volume
358group. (The VLF_RWEXITS flag is set when the read-write volume is created.)
359
360volumeId[1] is the volume id allocated for read-only volumes in this volume
361group. This number is allocated when the entry is created. (The VLF_ROEXISTS
362flag is set when a read-only volume is created.)
363
364volumeId[2] is the volume id allocated for the backup volume in this volume
365group, if one. This number is allocated when the entry is created. (The
366VLF_BACKEXISTS flag is set when a backup volume is created.)
367
368flags is a bitmap which indicates the vl entry state:
369
3700x0001 VLFREE indicates this entry is on the free list
3710x0002 VLDELETE indicates this entry is deleted
3720x0004 VLLOCKED not used; always zero
3730x0008 VLCONTBLOCK always zero in vl entries
3740x0010 VLOP_MOVE locked for a move operation
3750x0020 VLOP_RELEASE locked for a release operation
3760x0040 VLOP_BACKUP locked for a backup clone operation
3770x0080 VLOP_DELETE locked for a delete or addsite operation
3780x0100 VLOP_DUMP locked for a dump or restore operation
3790x1000 VLF_RWEXISTS this group has a read-write volume
3800x2000 VLF_ROEXISTS this group has at least one read-only volume
3810x4000 VLF_BACKEXISTS this group has a backup clone
3820x8000 VLF_DFSFILESET not used; always cleared
383
384High order bits of the flags field are reserved and should always be zero.
385
386LockAfsId is not used. This field is reserved to hold the id of the operator
387who locked the entry for a volume operation.
388
389LockTimestamp is the time stamp on the entry lock.
390
391cloneId is the volume id of the temporary clone volume, which may be
392created during volume operations.
393
394nextIdHash[0] has a dual role. The nextIdHash[0] is the logical address of the
395next vl entry on the read-write volume id hash chain when the VLFREE flag is
396unset. The nextIdHash[0] field is the logical address of the next vl entry on
397the free list when the VLFREE flag is set.
398
399nextIdHash[1] is the logical address of the next vl entry on the
400read-only volume id hash chain.
401
402nextIdHash[2] is the logical address of the next vl entry on the backup
403volume id hash chain.
404
405nextNameHash the logical address of the next vl entry on the volume name
406hash chain.
407
408name is a 65 octet field which holds the volume name, as a null
409terminated string.
410
411serverNumber, serverPartition, and serverFlags fields form a 13 row by 3
412column table. Each row describes a volume site. Empty rows are filled with
4130xFF instead of zero.
414
415serverNumber is a number from 0 to 254. The IpMappedAddr record at the
416serverNumber offset has a reference to a multi-homed (mh) entry. The mh entry
417holds the fileserver uuid and one or more IPv4 addresses of the fileserver.
418
419serverPartition is a number from 0 to 255 which represents a file server
420partition, from /vicepa to /vicepih.
421
422serverFlags indicates the state of the volume site:
423
4240x01 VLSF_NEWREPSITE read-only volume added to vldb, but not released yet
4250x02 VLSF_ROVOL a read-only volume is present at this location (see Notes)
4260x04 VLSF_RWVOL a read-write volume is present at this location (see Notes)
4270x08 VLSF_BACKVOL a backup volume is present at this location (see Notes)
4280x10 VLSF_UUID not used in the vldb; always zero
4290x20 VLSF_DONTUSE out of date read-only volume
4300x40 VLSF_RWREPLICA reserved for volume is a read-write replica
431
432Notes:
433
4341. In practice, one, and only one, of the VLSF_ROVOL, VLSF_RWVOL, VLSF_BACKVOL
435 flags are set per table row.
436
4372. In practice, the VLSF_BACKVOL flag is not used. Instead the VLF_BACKEXISTS
438 is set in the vl entry to indicate a backup clone is present on the same
439 fileserver and partition as the read-write volume. This saves an entry
440 in the table to allow for more read-only sites.
441
442
443Multi-homed Extension Block
444
445Multi-homed extension blocks are 8192 octets in size. The first 128 octets hold
446a header, which is mostly unused. The header is immediately followed by 63 mh
447entry slots, each 128 octets in size.
448
449Up to 4 blocks may be present in the vldb. The address of the first block is
450held in the SIT field of the vldb header. Addresses of the first and
451additional blocks are held in the contaddr field of the first block.
452
453Note: In the current format, the vldb is limited to 4 blocks, and 63 mh entries
454per block, which means the vldb is limited to 252 different mh servers, which
455is three less than the maximum number of server numbers (255).
456
457
458Multi-homed Extension Block Header
459
460The layout of the mh extension block header is:
461
462 0 1 2 3
463 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
464octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
465 0 | count |
466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
467 4 | reserved[0] |
468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
469 8 | reserved[1] |
470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
471 12 | flags |
472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
473 16 | contaddr[0] |
474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
475 20 | contaddr[1] |
476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
477 24 | contaddr[2] |
478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
479 28 | contaddr[3] |
480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
481 32 | reserved |
482 + +
483 | |
484 ~ ... ~
485 124 | |
486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
487
488count is not used.
489
490reserved[0], reserved[1] should always be zero.
491
492flags must have the VLCONTBLOCK bit set to indicate this is a 8192 octet
493mh extension block. All other bits in this field should be zero.
494
495contaddrs is a table of the addresses of the mh extension blocks, including
496the first block.
497
498reserved should always be zero.
499
500
501Multi-homed Entry
502
503The mh entry contains information for a single file server. Each mh entry
504is 128 octets in size.
505
506 0 1 2 3
507 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
508octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
509 0 | uuid.time_low |
510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
511 4 | uuid.time_mid | uuid.time_hi_and_version |
512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
513 8 | uuid.clock_hi | uuid.clock_lo | uuid.node |
514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
515 12 | |
516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
517 16 | uniquifier |
518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
519 20 | addrs[0] |
520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
521 24 | addrs[1] |
522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
523 28 | addrs[2] |
524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
525 32 | addrs[3] |
526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
527 36 | addrs[4] |
528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
529 40 | addrs[5] |
530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
531 44 | addrs[6] |
532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
533 48 | addrs[7] |
534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
535 52 | addrs[8] |
536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
537 56 | addrs[9] |
538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
539 60 | addrs[10] |
540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
541 64 | addrs[11] |
542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
543 68 | addrs[12] |
544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
545 72 | addrs[13] |
546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
547 76 | addrs[14] |
548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
549 80 | flags |
550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
551 84 | reserved |
552 ~ ... ~
553 124 | |
554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
555
556
557uuid is the universal unique id the fileserver used when registering
558with the vldb.
559
560uniquifier is a serial number of the mh entry. The first mh entry is assigned a
561uniquifier of 1. The uniquifier is incremented each time its containing entry
562is modified.
563
564addrs[0..14] holds a list of IPv4 addresses for this fileserver, each in
565network byte order. Zero indicates an empty slot.
566
567flags is reserved and should always be zero.
568
569reserved should always be zero.
570