| 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 | |