Commit | Line | Data |
---|---|---|
805e021f CE |
1 | |
2 | This document describes version 4 of the OpenAFS Volume Location Database | |
3 | (VLDB) file format. | |
4 | ||
5 | ||
6 | VLDB file layout | |
7 | ||
8 | The vldb.DB0 file consists of 64 octet ubik header, followed by a 132,120 octet | |
9 | vldb header, followed a variable number of vldb records. Records are either a | |
10 | 148 octet volume location (vl) entry or a 8192 octet multi-homed (mh) extension | |
11 | block. A bit flag at a fixed offset of each record specifies the record type. | |
12 | A field in the vldb header indicates the location of the last record. Any data | |
13 | in the file following the last record is ignored. | |
14 | ||
15 | ||
16 | Ubik header | |
17 | ||
18 | The vldb.DB0 file begins with a 64 octet ubik header. All fields are in | |
19 | network byte order. Only the first 16 octets of the ubik header are used. The | |
20 | unused fields should always be zero. The first 16 octets of the ubik header | |
21 | contain the representation of a struct ubik_hdr, with all the fields in network | |
22 | byte 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 | ||
62 | magic is the ubik file identification. It should always be 0x00354545. | |
63 | ||
64 | pad1 is unused, should always be 0 | |
65 | ||
66 | header_size is the size of the ubik header (including unused space), should always | |
67 | be 0x40 | |
68 | ||
69 | epoch is the ubik quorum epoch value. | |
70 | ||
71 | counter is the ubik counter for transactions and updates. | |
72 | ||
73 | unused space should always be zero. | |
74 | ||
75 | ||
76 | The ubik header is not exposed through the VL_ RPC package, and as such is not | |
77 | considered to be part of the logical VLDB database. | |
78 | ||
79 | Subsequent discussion will refer to VLDB addresses, or simply addresses. A | |
80 | VLDB address is a logical offset to a data within the VLDB. The physical file | |
81 | offset of data referenced by a VLDB address is the VLDB address plus the size | |
82 | of the ubik header (64 octets). | |
83 | ||
84 | ||
85 | VLDB header | |
86 | ||
87 | The VLDB header follows the ubik_header. It is the logical beginning of the | |
88 | VLDB. The VLDB header is 132120 octets in size. The majority of this space | |
89 | contains four hash tables enabling quick lookups of volumes by name and id. | |
90 | All integer fields are stored in network byte order. | |
91 | ||
92 | The 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 | |
96 | octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
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 | ~ ... ~ | |
135 | 132112 | | | |
136 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
137 | 132116 | 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 | ||
142 | vldbversion is the vldb disk format version number. This document describes | |
143 | version 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 | ||
149 | headersize is the size in octets of the vldb header, currently 0x020418 (132120) | |
150 | ||
151 | freePtr is the logical address in octets of the first in a linked list of | |
152 | unused vldb entries in the vldb database file (that is the first logical hole | |
153 | in the database file). This value is zero if the database is densely packed. | |
154 | The physical file offset to the first free entry is the freePtr value plus the | |
155 | size of the ubik header (64 octets). Every free vl entry in the vldb should be | |
156 | on the free list. The nextIdHash[0] vl entry field holds the address of the | |
157 | next vl entry on the free list. | |
158 | ||
159 | eofPtr is the logical address in octets of the end of the database file. When a | |
160 | new entry is created that extends the database file, it will be created at this | |
161 | logical index.The physical file offset to the end of the database file eofPtr | |
162 | value plus the size of the ubik header (64 octets). | |
163 | ||
164 | allocs is the number of calls to AllocBlock(), for statistical purposes. | |
165 | ||
166 | frees is the number of calls to FreeBlock(), for statistical purposes. | |
167 | ||
168 | MaxVolumeId is the largest volume id allocated. It is incremented every time | |
169 | a volume is created. | |
170 | ||
171 | TotalEntries[0] is the number of read-write volume entries. | |
172 | ||
173 | TotalEntries[1] is the number of read/only volume entries. | |
174 | ||
175 | TotalEntries[2] is the number of backup volume entries. | |
176 | ||
177 | IpMappedAddr maps vl entry serverNumbers to file server information. The vl | |
178 | entry serverNumber field is used as an offset into the IpMappedAddr table. The | |
179 | IpMappedaddr is a table of 255 records, one for each possible serverNumber, | |
180 | from 0 to 254. Each record is a 32 bit integer in network byte order. Empty | |
181 | records should be zero filled. | |
182 | ||
183 | IpMappedAddr records hold either a reference to a mh entry or a single IPv4 | |
184 | address. Records which contain 0xFF in the first octet are references to mh | |
185 | entries. Non-zero records which do not contain 0xFF in the first octet hold a | |
186 | single IPv4 address in network byte order. | |
187 | ||
188 | The 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 | ||
195 | 0xFF in the first octet indicates the record contains a multi-homed entry | |
196 | reference, instead of an IPv4 address. | |
197 | ||
198 | base is the mh extension block number; supported range is 0 to 3. | |
199 | ||
200 | index is the index to the mh entry within the mh extension block; supported range | |
201 | is 1 to 63. (Index of 0 is reserved for the mh extension block header.) | |
202 | ||
203 | Following the index are four hash tables, each containing 8191 (a prime number) | |
204 | 32-bit entries in network byte order. Each entry represents a hash bucket and | |
205 | holds the address of the vl entry at the head of the hash chain, or zero to | |
206 | indicate an empty hash bucket. Every vl entry which is not free should be in | |
207 | all four hashes. | |
208 | ||
209 | VolnameHash is the hash table for searches by volume name. The nextNameHash | |
210 | field at the head of the chain holds the address of the next vl entry in the | |
211 | hash chain. | |
212 | ||
213 | The NameHash hash function is targetted for ASCII text and is similar to the | |
214 | PRDB name hash function. Each octet of the volume name is treated as an | |
215 | unsigned integer from which 63 (decimal) is subtracted, and the resulting | |
216 | stream of integers is used as the coefficients of a power series with base 63 | |
217 | (decimal), with the least significant coefficient appearing first. | |
218 | ||
219 | For example, for a volume name string string of "abc", which is the stream | |
220 | of octets (in decimal): | |
221 | ||
222 | 97 98 99 | |
223 | ||
224 | then 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 | ||
229 | The value of this power series is stored in an unsigned 32-bit integer, and as | |
230 | such is implicitly computed modulo 2**32. The remainder modulo 8191 (the size | |
231 | of the hash table) of this 32-bit value is used as the index into the hash | |
232 | table for this name entry. (This hash function can be easily implemented | |
233 | iteratively.) | |
234 | ||
235 | ||
236 | VolidHash[0] is the hash table for searches by read-write volume ID. The | |
237 | nextIdHash[0] field at the head of the chain holds the address of the next vl | |
238 | entry in the hash chain. | |
239 | ||
240 | VolidHash[1] is the read-only volume ID to vldb entry hash table. The | |
241 | nextIdHash[1] field at the head of the chain holds the address of the next vl | |
242 | entry in the hash chain. | |
243 | ||
244 | VolidHash[2] is the backup volume ID to vldb entry hash table. The | |
245 | nextIdHash[2] field at the head of the chain holds the address of the next vl | |
246 | entry in the hash chain. | |
247 | ||
248 | The VolidHash hash function the remainder modulo 8191 (the size of the hash | |
249 | table) of the absolute value of the volume id. | |
250 | ||
251 | ||
252 | SIT holds the logical address of the first multi-homed extension block in the | |
253 | vldb. Each multi-homed extension block holds 4 logical addresses to additional | |
254 | multi-homed extension blocks. | |
255 | ||
256 | ||
257 | VLDB Records | |
258 | ||
259 | VLDB Records follow immediately after the VLDB header. Each record is either a | |
260 | 148 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 | ||
266 | The only invariant field is the single bit field which indicates the | |
267 | record 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 | |
271 | octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
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 | ||
285 | C is the continuation block flag (VLCONTBLOCK). A value of 0 indicates the | |
286 | record is a 148 octet vl entry. A value of 1 indicates the record is a 8192 | |
287 | octet mh extension block. | |
288 | ||
289 | ||
290 | VL Entry | |
291 | ||
292 | The 148 octet vl entry maps a volume group to a set of file server locations | |
293 | for each volume in the volume group. A volume group consists of a single | |
294 | read-write volume, zero or one backup volumes, zero or more read-only volumes, | |
295 | and zero or one temporary clone volumes. | |
296 | ||
297 | The vl entry also holds information for volume administration. | |
298 | ||
299 | All integer fields are in network byte order. | |
300 | ||
301 | The 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 | |
305 | octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
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 | ||
357 | volumeId[0] is the volume id allocated for the read-write volume in this volume | |
358 | group. (The VLF_RWEXITS flag is set when the read-write volume is created.) | |
359 | ||
360 | volumeId[1] is the volume id allocated for read-only volumes in this volume | |
361 | group. This number is allocated when the entry is created. (The VLF_ROEXISTS | |
362 | flag is set when a read-only volume is created.) | |
363 | ||
364 | volumeId[2] is the volume id allocated for the backup volume in this volume | |
365 | group, if one. This number is allocated when the entry is created. (The | |
366 | VLF_BACKEXISTS flag is set when a backup volume is created.) | |
367 | ||
368 | flags is a bitmap which indicates the vl entry state: | |
369 | ||
370 | 0x0001 VLFREE indicates this entry is on the free list | |
371 | 0x0002 VLDELETE indicates this entry is deleted | |
372 | 0x0004 VLLOCKED not used; always zero | |
373 | 0x0008 VLCONTBLOCK always zero in vl entries | |
374 | 0x0010 VLOP_MOVE locked for a move operation | |
375 | 0x0020 VLOP_RELEASE locked for a release operation | |
376 | 0x0040 VLOP_BACKUP locked for a backup clone operation | |
377 | 0x0080 VLOP_DELETE locked for a delete or addsite operation | |
378 | 0x0100 VLOP_DUMP locked for a dump or restore operation | |
379 | 0x1000 VLF_RWEXISTS this group has a read-write volume | |
380 | 0x2000 VLF_ROEXISTS this group has at least one read-only volume | |
381 | 0x4000 VLF_BACKEXISTS this group has a backup clone | |
382 | 0x8000 VLF_DFSFILESET not used; always cleared | |
383 | ||
384 | High order bits of the flags field are reserved and should always be zero. | |
385 | ||
386 | LockAfsId is not used. This field is reserved to hold the id of the operator | |
387 | who locked the entry for a volume operation. | |
388 | ||
389 | LockTimestamp is the time stamp on the entry lock. | |
390 | ||
391 | cloneId is the volume id of the temporary clone volume, which may be | |
392 | created during volume operations. | |
393 | ||
394 | nextIdHash[0] has a dual role. The nextIdHash[0] is the logical address of the | |
395 | next vl entry on the read-write volume id hash chain when the VLFREE flag is | |
396 | unset. The nextIdHash[0] field is the logical address of the next vl entry on | |
397 | the free list when the VLFREE flag is set. | |
398 | ||
399 | nextIdHash[1] is the logical address of the next vl entry on the | |
400 | read-only volume id hash chain. | |
401 | ||
402 | nextIdHash[2] is the logical address of the next vl entry on the backup | |
403 | volume id hash chain. | |
404 | ||
405 | nextNameHash the logical address of the next vl entry on the volume name | |
406 | hash chain. | |
407 | ||
408 | name is a 65 octet field which holds the volume name, as a null | |
409 | terminated string. | |
410 | ||
411 | serverNumber, serverPartition, and serverFlags fields form a 13 row by 3 | |
412 | column table. Each row describes a volume site. Empty rows are filled with | |
413 | 0xFF instead of zero. | |
414 | ||
415 | serverNumber is a number from 0 to 254. The IpMappedAddr record at the | |
416 | serverNumber offset has a reference to a multi-homed (mh) entry. The mh entry | |
417 | holds the fileserver uuid and one or more IPv4 addresses of the fileserver. | |
418 | ||
419 | serverPartition is a number from 0 to 255 which represents a file server | |
420 | partition, from /vicepa to /vicepih. | |
421 | ||
422 | serverFlags indicates the state of the volume site: | |
423 | ||
424 | 0x01 VLSF_NEWREPSITE read-only volume added to vldb, but not released yet | |
425 | 0x02 VLSF_ROVOL a read-only volume is present at this location (see Notes) | |
426 | 0x04 VLSF_RWVOL a read-write volume is present at this location (see Notes) | |
427 | 0x08 VLSF_BACKVOL a backup volume is present at this location (see Notes) | |
428 | 0x10 VLSF_UUID not used in the vldb; always zero | |
429 | 0x20 VLSF_DONTUSE out of date read-only volume | |
430 | 0x40 VLSF_RWREPLICA reserved for volume is a read-write replica | |
431 | ||
432 | Notes: | |
433 | ||
434 | 1. In practice, one, and only one, of the VLSF_ROVOL, VLSF_RWVOL, VLSF_BACKVOL | |
435 | flags are set per table row. | |
436 | ||
437 | 2. 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 | ||
443 | Multi-homed Extension Block | |
444 | ||
445 | Multi-homed extension blocks are 8192 octets in size. The first 128 octets hold | |
446 | a header, which is mostly unused. The header is immediately followed by 63 mh | |
447 | entry slots, each 128 octets in size. | |
448 | ||
449 | Up to 4 blocks may be present in the vldb. The address of the first block is | |
450 | held in the SIT field of the vldb header. Addresses of the first and | |
451 | additional blocks are held in the contaddr field of the first block. | |
452 | ||
453 | Note: In the current format, the vldb is limited to 4 blocks, and 63 mh entries | |
454 | per block, which means the vldb is limited to 252 different mh servers, which | |
455 | is three less than the maximum number of server numbers (255). | |
456 | ||
457 | ||
458 | Multi-homed Extension Block Header | |
459 | ||
460 | The 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 | |
464 | octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
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 | ||
488 | count is not used. | |
489 | ||
490 | reserved[0], reserved[1] should always be zero. | |
491 | ||
492 | flags must have the VLCONTBLOCK bit set to indicate this is a 8192 octet | |
493 | mh extension block. All other bits in this field should be zero. | |
494 | ||
495 | contaddrs is a table of the addresses of the mh extension blocks, including | |
496 | the first block. | |
497 | ||
498 | reserved should always be zero. | |
499 | ||
500 | ||
501 | Multi-homed Entry | |
502 | ||
503 | The mh entry contains information for a single file server. Each mh entry | |
504 | is 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 | |
508 | octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
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 | ||
557 | uuid is the universal unique id the fileserver used when registering | |
558 | with the vldb. | |
559 | ||
560 | uniquifier is a serial number of the mh entry. The first mh entry is assigned a | |
561 | uniquifier of 1. The uniquifier is incremented each time its containing entry | |
562 | is modified. | |
563 | ||
564 | addrs[0..14] holds a list of IPv4 addresses for this fileserver, each in | |
565 | network byte order. Zero indicates an empty slot. | |
566 | ||
567 | flags is reserved and should always be zero. | |
568 | ||
569 | reserved should always be zero. | |
570 |