Restructure directories
[openafs-wiki.git] / devel / DemandAttach.mdwn
1 [[!toc levels=3]]
2
3 #  Demand-Attach File-Server (DAFS)
4
5 OpenAFS 1.5 contains Demand-Attach File-Server (DAFS). DAFS is a significant departure from the more _traditional_ AFS file-server and this document details those changes.
6
7 ##  Why Demand-Attach File-Server (DAFS) ?
8
9 On a traditional file-server, volumes are attached at start-up and detached only at shutdown. Any attached volume can be modified and changes are periodically flushed to disk or on shutdown. When a file-server isn't shutdown cleanly, the integrity of every attached volume has to be verified by the salvager, whether the volume had been modified or not. As file-servers grow larger (and the number of volumes increase), the length of time required to salvage and attach volumes increases, e.g. it takes around two hours for a file-server housing 512GB data to salvage and attach volumes !
10
11 On a Demand-Attach File-Server (DAFS), volumes are attached only when accessed by clients. On start-up, the file-server reads only the volume headers to determine what volumes reside on what partitions. When accessed by clients, the volumes are attached. After some period of inactivity, volumes are automatically detached. This dramatically improves start-up and shutdown times. A demand-attach file-server can be restarted in seconds compared to hours for the same traditional file-server.
12
13 The primary objective of the demand-attach file-server was to dramatically reduce the amount of time required to restart an AFS file-server.
14
15 Large portions of this document were taken / influenced by the presentation entitled [Demand Attach / Fast-Restart Fileserver](http://workshop.openafs.org/afsbpw06/talks/tkeiser-dafs.pdf) given by Tom Keiser at the [AFS and Kerberos Best Practices Workshop](http://workshop.openafs.org/) in [2006](http://workshop.openafs.org/afsbpw06/).
16
17 ##  An Overview of Demand-Attach File-Server
18
19 Demand-attach necessitated a significant re-design of certain aspects of the AFS code, including:
20
21 - volume package has a number of severe limitations
22   - single global lock, leading to poor scaling
23   - lock is held across high latency operations, e.g. disk I/O
24   - no notion of state for concurrently accessed objects
25 - the vnode package suffers from the same limitations
26 - breaking callbacks is time consuming
27 - salvaging does not have to be done with the file-server offline
28
29 The changes implemented for demand-attach include:
30
31 - [[volume finite-state automata|DemandAttach#Volume_Finite_State_Automata]]
32 - volumes are attached on demand
33 - volume _garbage collector_ to detach unused volumes
34 - notion of volume state means read-only volumes aren't salvaged
35 - [[vnode finite-state automata|DemandAttach#Vnode_Finite_State_Automata]]
36 - global lock is only held when required and never held across high-latency operations
37 - automatic salvaging of volumes
38 - shutdown is done in parallel (maximum number of threads utilized)
39 - callbacks are no longer broken on shutdown
40 - instead, host / callback state is preserved across restarts
41
42 ##  The Gory Details of the Demand-Attach File-Server
43
44 ###  Bos Configuration 
45 A traditional file-server uses the `bnode` type `fs` and has a definition similar to
46
47     bnode fs fs 1
48     parm /usr/afs/bin/fileserver -p 123 -L -busyat 200 -rxpck 2000 -cb 4000000 
49     parm /usr/afs/bin/volserver -p 127 -log 
50     parm /usr/afs/bin/salvager -parallel all32
51     end
52
53 Since an additional component was required for the demand-attach file-server, a new `bnode` type ( `dafs`) is required. The definition should be similar to
54
55     bnode dafs dafs 1
56     parm /usr/afs/bin/dafileserver -p 123 -L -busyat 200 -rxpck 2000 -cb 4000000 -vattachpar 128 -vlruthresh 1440 -vlrumax 8 -vhashsize 11
57     parm /usr/afs/bin/davolserver -p 64 -log 
58     parm /usr/afs/bin/salvageserver
59     parm /usr/afs/bin/dasalvager -parallel all32
60     end
61
62 The instance for a demand-attach file-server is therefore `dafs`
63 instead of `fs`.  For a complete list of configuration options see the
64 [dafileserver man page](http://docs.openafs.org/Reference/8/dafileserver.html).
65
66 ### <a name="File-server Start-up / Shutdown "></a> File-server Start-up / Shutdown Sequence
67
68 The table below compares the start-up sequence for a traditional file-server and a demand-attach file-server.
69
70 <table border="1" cellpadding="0" cellspacing="0">
71   <tr>
72     <th bgcolor="#99CCCC"><strong> Traditional </strong></th>
73     <th bgcolor="#99CCCC"><strong> Demand-Attach </strong></th>
74   </tr>
75   <tr>
76     <td>   </td>
77     <td>  host / callback state restored </td>
78   </tr>
79   <tr>
80     <td>   </td>
81     <td>  host / callback state consistency verified </td>
82   </tr>
83   <tr>
84     <td>  build vice partition list </td>
85     <td>  build vice partition list </td>
86   </tr>
87   <tr>
88     <td>  volumes are attached </td>
89     <td>  volume headers read </td>
90   </tr>
91   <tr>
92     <td>   </td>
93     <td>  volumes placed into <em>pre-attached</em> state </td>
94   </tr>
95 </table>
96
97 The [[host / callback state|DemandAttach#FSStateDat]] is covered later. The _pre-attached_ state indicates that the file-server has read the volume headers and is aware that the volume exists, but that it has not been attached (and hence is not on-line).
98
99 The shutdown sequence for both file-server types is:
100
101 <table border="1" cellpadding="0" cellspacing="0">
102   <tr>
103     <th bgcolor="#99CCCC"><strong> Traditional </strong></th>
104     <th bgcolor="#99CCCC"><strong> Demand-Attach </strong></th>
105   </tr>
106   <tr>
107     <td>  break callbacks </td>
108     <td>  quiesce host / callback state </td>
109   </tr>
110   <tr>
111     <td>  shutdown volumes </td>
112     <td>  shutdown on-line volumes </td>
113   </tr>
114   <tr>
115     <td>   </td>
116     <td>  verify host / callback state consistency </td>
117   </tr>
118   <tr>
119     <td>   </td>
120     <td>  save host / callback state </td>
121   </tr>
122 </table>
123
124 On a traditional file-server, volumes are off-lined (detached) serially. In demand-attach, as many threads as possible are used to detach volumes, which is possible due to the notion of a volume has an associated state.
125
126 ###  Volume Finite-State Automata
127
128 The volume finite-state automata is available in the source tree under `doc/arch/dafs-fsa.dot`. See [[=fssync-debug=|DemandAttach#fssync_debug]] for information on debugging the volume package.
129
130
131
132 ###  Volume Least Recently Used (VLRU) Queues
133
134 The Volume Least Recently Used (VLRU) is a garbage collection facility which automatically off-lines volumes in the background. The purpose of this facility is to pro-actively off-line infrequently used volumes to improve shutdown and salvage times. The process of off-lining a volume from the "attached" state to the "pre-attached" state is called soft detachment.
135
136 VLRU works in a manner similar to a generational garbage collector. There are five queues on which volumes can reside.
137
138 <table border="1" cellpadding="0" cellspacing="0">
139   <tr>
140     <th bgcolor="#99CCCC"><strong> Queue </strong></th>
141     <th bgcolor="#99CCCC"><strong> Meaning </strong></th>
142   </tr>
143   <tr>
144     <td> candidate </td>
145     <td> Volumes which have not been accessed recently and hence are candidates for soft detachment. </td>
146   </tr>
147   <tr>
148     <td> held </td>
149     <td> Volumes which are administratively prevented from VLRU activity, i.e. will never be detached. </td>
150   </tr>
151   <tr>
152     <td> intermediate (mid) </td>
153     <td> Volumes transitioning from new -&gt; old (see [[DemandAttach#VLRUStateTransitions][state transitions] for details). </td>
154   </tr>
155   <tr>
156     <td> new </td>
157     <td> Volumes which have been accessed. See [[DemandAttach#VLRUStateTransitions][state transitions] for details. </td>
158   </tr>
159   <tr>
160     <td> old </td>
161     <td> Volumes which are continually accessed. See [[DemandAttach.#VLRUStateTransitions][state transitions] for details. </td>
162   </tr>
163 </table>
164
165 The state of the various VLRU queues is dumped with the file-server state and at shutdown.
166
167  The VLRU queues new, mid (intermediate) and old are generational queues for active volumes. State transitions are controlled by inactivity timers and are
168
169 <table border="1" cellpadding="0" cellspacing="0">
170   <tr>
171     <th bgcolor="#99CCCC"><strong> Transition </strong></th>
172     <th bgcolor="#99CCCC"><strong> Timeout (minutes) </strong></th>
173     <th bgcolor="#99CCCC"><strong> Actual Timeout (in MS) </strong></th>
174     <th bgcolor="#99CCCC"><strong> Reason (since last transition) </strong></th>
175   </tr>
176   <tr>
177     <td> candidate-&gt;new </td>
178     <td> - </td>
179     <td> - </td>
180     <td> new activity </td>
181   </tr>
182   <tr>
183     <td> new-&gt;candidate </td>
184     <td> 1 * vlruthresh </td>
185     <td> 24 hrs </td>
186     <td> no activity </td>
187   </tr>
188   <tr>
189     <td> new-&gt;mid </td>
190     <td> 2 * vlruthresh </td>
191     <td> 48 hrs </td>
192     <td> activity </td>
193   </tr>
194   <tr>
195     <td> mid-&gt;old </td>
196     <td> 4 * vlruthresh </td>
197     <td> 96 hrs </td>
198     <td> activity </td>
199   </tr>
200   <tr>
201     <td> old-&gt;mid </td>
202     <td> 2 * vlruthresh </td>
203     <td> 48 hrs </td>
204     <td> no activity </td>
205   </tr>
206   <tr>
207     <td> mid-&gt;new </td>
208     <td> 1 * vlruthresh </td>
209     <td> 24 hrs </td>
210     <td> no activity </td>
211   </tr>
212 </table>
213
214 `vlruthresh` has been optimized for RO file-servers, where volumes are frequently accessed once a day and soft-detaching has little effect (RO volumes are not salvaged; one of the main reasons for soft detaching).
215
216 ###  Vnode Finite-State Automata
217
218 The vnode finite-state automata is available in the source tree under `doc/arch/dafs-vnode-fsa.dot`
219
220 `/usr/afs/bin/fssync-debug` provides low-level inspection and control of the file-server volume package. **Indiscriminate use of <code>fsync-debug</code>** can lead to extremely bad things occurring. Use with care. 
221
222
223
224 ###  Demand Salvaging
225
226 Demand salvaging is implemented by the `salvageserver`. The actual code for salvaging a volume remains largely unchanged. However, the method for invoking salvaging with demand-attach has changed:
227
228 - file-server automatically requests volumes be salvaged as required, i.e. they are marked as requiring salvaging when attached.
229 - manual initiation of salvaging may be required when access is through the `volserver` (may be addressed at some later date).
230 - `bos salvage` requires the `-forceDAFS` flag to initiate salvaging with DAFS. However, **salvaging should not be initiated using this method**.
231 - infinite salvage, attach, salvage, ... loops are possible. There is therefore a hard-limit on the number of times a volume will be salvaged which is reset when the volume is removed or the file-server is restarted.
232 - volumes are salvaged in parallel and is controlled by the `-Parallel` argument to the `salvageserver`. Defaults to 4.
233 - the `salvageserver` and the `inode` file-server are incompatible:
234   - because volumes are inter-mingled on a partition (rather than being separated), a lock for the entire partition on which the volume is located is held throughout. Both the `fileserver` and `volserver` will block if they require this lock, e.g. to restore / dump a volume located on the partition.
235   - inodes for a particular volume can be located anywhere on a partition. Salvaging therefore results in **every** inode on a partition having to be read to determine whether it belongs to the volume. This is extremely I/O intensive and leads to horrendous salvaging performance.
236 - `/usr/afs/bin/salvsync-debug` provides low-level inspection and control over the `salvageserver`. **Indiscriminate use of `salvsync-debug` can lead to extremely bad things occurring. Use with care.**
237 - See [[=salvsync-debug=|DemandAttach#salvsync_debug]] for information on debugging problems with the salvageserver.
238
239
240
241 ###  File-Server Host / Callback State
242
243 Host / callback information is persistent across restarts with demand-attach. On shutdown, the file-server writes the data to `/usr/afs/local/fsstate.dat`. The contents of this file are read and verified at start-up and hence it is unnecessary to break callbacks on shutdown with demand-attach.
244
245 The contents of `fsstate.dat` can be inspected using `/usr/afs/bin/state_analyzer`.
246
247 ## <a name="File-Server Arguments (relating "></a> File-Server Arguments (relating to Demand-Attach)
248
249 These are available in the man-pages (section 8) for the fileserver; some details are provided here for convenience:
250
251 Arguments controlling the host / callback state:
252
253 <table border="1" cellpadding="0" cellspacing="0">
254   <tr>
255     <th bgcolor="#99CCCC"><strong> Parameter </strong></th>
256     <th bgcolor="#99CCCC"><strong> Options </strong></th>
257     <th bgcolor="#99CCCC"><strong> Default </strong></th>
258     <th bgcolor="#99CCCC"><strong> Suggested Value </strong></th>
259     <th bgcolor="#99CCCC"><strong> Meaning </strong></th>
260   </tr>
261   <tr>
262     <td><code>fs-state-dont-save</code></td>
263     <td> n/a </td>
264     <td> state saved </td>
265     <td> - </td>
266     <td><code>fileserver</code> state will not be saved during shutdown </td>
267   </tr>
268   <tr>
269     <td><code>fs-state-dont-restore</code></td>
270     <td> n/a </td>
271     <td> state restored </td>
272     <td> - </td>
273     <td><code>fileserver</code> state will not be restored during startup </td>
274   </tr>
275   <tr>
276     <td><code>fs-state-verify</code></td>
277     <td> n/a </td>
278     <td> both </td>
279     <td> - </td>
280     <td> Controls the behavior of the state verification mechanism. Before saving or restoring the <code>fileserver</code> state information, the internal host and callback data structures are verified. A value of 'none' turns off all verification. A value of 'save' only performs the verification steps prior to saving state to disk. A value of 'restore' only performs the verification steps after restoring state from disk. A value of 'both' performs all verification steps both prior to saving and after restoring state. </td>
281   </tr>
282 </table>
283
284 Arguments controlling the VLRU
285
286 <table border="1" cellpadding="0" cellspacing="0">
287   <tr>
288     <th bgcolor="#99CCCC"><strong> Parameter </strong></th>
289     <th bgcolor="#99CCCC"><strong> Options </strong></th>
290     <th bgcolor="#99CCCC"><strong> Default </strong></th>
291     <th bgcolor="#99CCCC"><strong> Suggested Value </strong></th>
292     <th bgcolor="#99CCCC"><strong> Meaning </strong></th>
293   </tr>
294   <tr>
295     <td><code>vattachpar</code></td>
296     <td> positive integer </td>
297     <td> 1 </td>
298     <td> 128 </td>
299     <td> Controls the parallelism of the volume package start-up and shutdown routines. On start-up, vice partitions are scanned for volumes to pre-attach using a number of worker threads, the number of which is the minimum of <code>vattachpar</code> or the number of vice partitions. On shutdown, <code>vattachpar</code> worker threads are used to detach volumes. The shutdown code is mp-scaleable well beyond the number of vice partitions. Tom Keiser (from SNA) found 128 threads for a single vice partition had a statistically significant performance improvement over 64 threads. </td>
300   </tr>
301   <tr>
302     <td><code>vhashsize</code></td>
303     <td> positive integer </td>
304     <td> 8 </td>
305     <td> 11 </td>
306     <td> This parameter controls the size of the volume hash table. The table will contain 2^( <code>vhashsize</code>) entries. Hash bucket utilization statistics are given in the <code>fileserver</code> state information as well as on shutdown. </td>
307   </tr>
308   <tr>
309     <td><code>vlrudisable</code></td>
310     <td> n/a </td>
311     <td> enabled </td>
312     <td> - </td>
313     <td> Disables the Volume Least Recently Used (VLRU) cache. </td>
314   </tr>
315   <tr>
316     <td><code>vlruthresh</code></td>
317     <td> positive integer </td>
318     <td> 120 minutes </td>
319     <td> 1440 (24 hrs) </td>
320     <td> Minutes of inactivity before a volume is eligible for soft detachment. </td>
321   </tr>
322   <tr>
323     <td><code>vlruinterval</code></td>
324     <td> positive integer </td>
325     <td> 120 seconds </td>
326     <td> - </td>
327     <td> Number of seconds between VLRU candidate queue scans </td>
328   </tr>
329   <tr>
330     <td><code>vlrumax</code></td>
331     <td> positive integer </td>
332     <td> 8 </td>
333     <td> 8 </td>
334     <td> Max number of volumes which will be soft detached in a single pass of the scanner </td>
335   </tr>
336 </table>
337
338 ##  Tools for Debugging Demand-Attach File-Server
339
340 Several tools aid debugging problems with demand-attach file-servers. They operate at an extremely low-level and hence require a detailed knowledge of the architecture / code.
341
342 ###  <code>**fssync-debug**</code>
343
344 **Indiscriminate use of `fssync-debug` can have extremely dire consequences. Use with care.** 
345
346 `fssync-debug` provides low-level inspection and control over the volume package of the file-server. It can be used to display the file-server information associated with a volume, e.g.
347
348     ozsaw7 2# vos exam user.af -cell w.ln
349     user.af                           537119916 RW    2123478 K  On-line
350       ln1qaf01 /vicepb
351       RWrite  537119916 ROnly          0 Backup  537119917
352       MaxQuota    3200000 K
353       Creation    Wed Sep 17 17:48:17 2003
354       Copy        Thu Dec 11 18:01:37 2008
355       Backup      Thu Jun 25 01:49:20 2009
356       Last Update Thu Jun 25 16:17:35 2009
357       85271 accesses in the past day (i.e., vnode references)
358
359       RWrite: 537119916     Backup: 537119917
360       number of sites -> 1
361          server ln1qaf01 partition /vicepb RW Site
362     ozsaw7 3# /usr/afs/bin/fssync-debug query -vol 537119916 -part /vicepb
363     calling FSYNC_VolOp with command code 65543 (FSYNC_VOL_QUERY)
364     FSYNC_VolOp returned 0 (SYNC_OK)
365     protocol response code was 0 (SYNC_OK)
366     protocol reason code was 0 (0)
367     volume = {
368           hashid          = 537119916
369           header          = 0xf93f160
370           device          = 1
371           partition       = 0xf90dfb8
372           linkHandle      = 0x10478400
373           nextVnodeUnique = 2259017
374           diskDataHandle  = 0x104783d0
375           vnodeHashOffset = 14
376           shuttingDown    = 0
377           goingOffline    = 0
378           cacheCheck      = 49167
379           nUsers          = 0
380           needsPutBack    = 0
381           specialStatus   = 0
382           updateTime      = 1245943107
383           vnodeIndex[vSmall] = {
384                   handle       = 0x104783a0
385                   bitmap       = 0x13f44df0
386                   bitmapSize   = 2792
387                   bitmapOffset = 64
388           }
389           vnodeIndex[vLarge] = {
390                   handle       = 0x10478370
391                   bitmap       = 0x13c96040
392                   bitmapSize   = 296
393                   bitmapOffset = 252
394           }
395           updateTime      = 1245943107
396           attach_state    = VOL_STATE_ATTACHED
397           attach_flags    = VOL_HDR_ATTACHED | VOL_HDR_LOADED | VOL_HDR_IN_LRU | VOL_IN_HASH | VOL_ON_VBYP_LIST | VOL_ON_VLRU
398           nWaiters        = 0
399           chainCacheCheck = 14
400           salvage = {
401                   prio      = 0
402                   reason    = 0
403                   requested = 0
404                   scheduled = 0
405           }
406           stats = {
407                   hash_lookups = {
408                           hi = 0
409                           lo = 459560
410                   }
411                   hash_short_circuits = {
412                           hi = 0
413                           lo = 30
414                   }
415                   hdr_loads = {
416                           hi = 0
417                           lo = 32
418                   }
419                   hdr_gets = {
420                           hi = 0
421                           lo = 456011
422                   }
423                   attaches         = 32
424                   soft_detaches    = 0
425                   salvages         = 1
426                   vol_ops          = 32
427                   last_attach      = 1245891030
428                   last_get         = 1245943107
429                   last_promote     = 1245891030
430                   last_hdr_get     = 1245943107
431                   last_hdr_load    = 1245891030
432                   last_salvage     = 1242508846
433                   last_salvage_req = 1242508846
434                   last_vol_op      = 1245890958
435           }
436           vlru = {
437                   idx = 0 (VLRU_QUEUE_NEW)
438           }
439           pending_vol_op  = 0x0
440     }
441
442 Note that the `volumeid` argument must be the numeric ID and the `partition` argument must be the **exact** partition name (and not an abbreviation). An explanation of all these values is beyond the scope of this document. The important fields are:
443
444 - `attach_state`, which is usually
445   - `VOL_STATE_PREATTACHED` which means the volume headers have been read, but the volume is not attached
446   - `VOL_STATE_ATTACHED` which means the volume is fully attached
447   - `VOL_STATE_ERROR` which indicates that the volume cannot be attached
448 - `attach_flags`
449   - `VOL_HDR_ATTACHED` means the volume headers have been read (and hence the file-server is aware of the volumes existence)
450   - `VOL_HDR_LOADED` means the volume headers are resident in memory
451   - `VOL_HDR_IN_LRU` means the volume headers are on the least-recently used queue
452   - `VOL_IN_HASH` indicates that the volume has been added to the volume linked-list
453   - `VOL_ON_VBYP_LIST` indicates that the volume is linked off the partition list
454   - `VOL_ON_VLRU` means the volume is on a VLRU queue
455 - the `salvage` structure (detailed [[here|DemandAttach#salvsync_debug]])
456 - the `stats` structure, particularly the volume operation times ( `last_*`).
457 - the `vlru` structure, particularly the VLRU queue
458
459 An understanding of the [volume finite-state machine](http://www.dementia.org/twiki//view/dafs-fsa.png) is required before the state of a volume should be manipulated.
460
461 ###  <code>**salvsync-debug**</code>
462
463 **Indiscriminate use of `salvsync-debug` can have extremely dire consequences. Use with care**
464
465 `salvsync-debug` provides low-level inspection and control of the salvageserver process, including the scheduling order of volumes.
466
467 `salvsync-debug` can be used to query the current salvage status of a volume, e,g,
468
469     ozsaw7 4# /usr/afs/bin/salvsync-debug query -vol 537119916 -part /vicepb
470     calling SALVSYNC_SalvageVolume with command code 65540 (SALVSYNC_QUERY)
471     SALVSYNC_SalvageVolume returned 0 (SYNC_OK)
472     protocol response code was 0 (SYNC_OK)
473     protocol reason code was 0 (**UNKNOWN**)
474     state = {
475           state = 4 (SALVSYNC_STATE_DONE)
476           prio = 0
477           sq_len = 0
478           pq_len = 0
479     }
480
481 To initiate the salvaging of a volume
482
483     ozsaw7 5# /usr/afs/bin/salvsync-debug salvage -vol 537119916 -part /vicepb
484     calling SALVSYNC_SalvageVolume with command code 65537 (SALVSYNC_SALVAGE)
485     SALVSYNC_SalvageVolume returned 0 (SYNC_OK)
486     protocol response code was 0 (SYNC_OK)
487     protocol reason code was 0 (**UNKNOWN**)
488     state = {
489           state = 1 (SALVSYNC_STATE_QUEUED)
490           prio = 0
491           sq_len = 1
492           pq_len = 0
493     }
494     ozsaw7 6# /usr/afs/bin/salvsync-debug query -vol 537119916 -part /vicepb calling SALVSYNC_SalvageVolume with command code 65540 (SALVSYNC_QUERY)
495     SALVSYNC_SalvageVolume returned 0 (SYNC_OK)
496     protocol response code was 0 (SYNC_OK)
497     protocol reason code was 0 (**UNKNOWN**)
498     state = {
499           state = 2 (SALVSYNC_STATE_SALVAGING)
500           prio = 0
501           sq_len = 0
502           pq_len = 1
503     }
504
505 This is the method that should be used on demand-attach file-servers to initiate the manual salvage of volumes. It should be used with care.
506
507 Under normal circumstances, the priority ( `prio`) of a salvage request is the number of times the volume has been requested by clients. Modifying the priority (and hence the order volumes are salvaged) under heavy demand-salvaging usually leads to extremely bad things happening.  To modify the priority of a request, use
508
509     salvsync-debug priority -vol 537119916 -part /vicepb -priority 999999
510
511 (where `priority` is a 32-bit integer).
512
513 ###  <code>**state\_analyzer**</code>
514
515 `state_analyzer` allows the contents of the host / callback state file ( `/usr/afs/local/fsstate.dat`) to be inspected.
516
517 ####  Header Information
518
519 Header information is gleaned through the `hdr` command
520
521     fs state analyzer> hdr
522     loading structure from address 0xfed80000 (offset 0)
523           fs_state_header = {
524                   stamp = {
525                           magic = 0x62fa841c
526                           version = 2
527                   }
528                   timestamp = "Tue Jun 23 11:51:49 2009"
529                   sys_name = 941
530                   server_uuid = "002e9712-ae67-1a2e-8a-42-900e866eaa77"
531                   valid = 0
532                   endianness = 1
533                   stats_detailed = 1
534                   h_offset = {
535                           hi = 0
536                           lo = 1024
537                   }
538                   cb_offset = {
539                           hi = 0
540                           lo = 93928
541                   }
542                   server_version_string = "@(#) OpenAFS 1.4.6-22 built  2009-04-18 "
543           }
544     fs state analyzer>
545
546 ####  Host Information
547
548 Host information can be gleaned through the `h` command, e.g.
549
550     fs state analyzer> h
551     fs state analyzer: h(0)> this
552     loading structure from address 0xfed80500 (offset 1280)
553           host_state_entry_header = {
554                   magic = 0xa8b9cadb
555                   len = 104
556                   interfaces = 2
557                   hcps = 0
558           }
559           hostDiskEntry = {
560                   host = "161.144.167.187"
561                   port = 7001
562                   hostFlags = 0x144
563                   Console = 0
564                   hcpsfailed = 0
565                   hcps_valid = 0
566                   InSameNetwork = 0
567                   hcps_len = 0
568                   LastCall = "Tue Jun 23 11:51:45 2009"
569                   ActiveCall = "Tue Jun 23 11:51:45 2009"
570                   cpsCall = "Tue Jun 23 11:51:45 2009"
571                   cblist = 21133
572                   index = 373
573           }
574           Interface = {
575                   numberOfInterfaces = 2
576                   uuid = "aae8a851-1d54-4b83-ad-17-db967bd89e1b"
577                   interface[0] = {
578                           addr = "161.144.167.187"
579                           port = 7001
580                   }
581                   interface[1] = {
582                           addr = "192.168.8.4"
583                           port = 7001
584                   }
585           }
586     fs state analyzer: h(0)> next
587     loading structure from address 0xfed80568 (offset 1384)
588           host_state_entry_header = {
589                   magic = 0xa8b9cadb
590                   len = 120
591                   interfaces = 4
592                   hcps = 0
593           }
594           hostDiskEntry = {
595                   host = "10.181.34.134"
596                   port = 7001
597                   hostFlags = 0x144
598                   Console = 0
599                   hcpsfailed = 0
600                   hcps_valid = 0
601                   InSameNetwork = 0
602                   hcps_len = 0
603                   LastCall = "Tue Jun 23 11:51:08 2009"
604                   ActiveCall = "Tue Jun 23 11:51:08 2009"
605                   cpsCall = "Tue Jun 23 11:51:08 2009"
606                   cblist = 8422
607                   index = 369
608           }
609           Interface = {
610                   numberOfInterfaces = 4
611                   uuid = "00107e94-794d-1a3d-ae-e2-0ab52421aa77"
612                   interface[0] = {
613                           addr = "10.181.36.33"
614                           port = 7001
615                   }
616                   interface[1] = {
617                           addr = "10.181.36.31"
618                           port = 7001
619                   }
620                   interface[2] = {
621                           addr = "10.181.32.134"
622                           port = 7001
623                   }
624                   interface[3] = {
625                           addr = "10.181.34.134"
626                           port = 7001
627                   }
628           }
629     fs state analyzer: h(1)>
630
631 ####  Callback Information
632
633 Callback information is available through the `cb` command, e.g.
634
635     fs state analyzer> cb
636     fs state analyzer: fe(0):cb(0)> dump
637     loading structure from address 0xfed97b6c (offset 97132)
638           CBDiskEntry = {
639                   cb = {
640                           cnext = 0
641                           fhead = 19989
642                           thead = 103
643                           status = 1
644                           hhead = 224
645                           tprev = 12276
646                           tnext = 22836
647                           hprev = 12276
648                           hnext = 22836
649                   }
650                   index = 6774
651           }
652
653 The `dump` command (as opposed to `this`) displays all call-backs for the current file-entry. Moving to the next file-entry can be achieved by
654
655     fs state analyzer: fe(0):cb(0)> quit
656     fs state analyzer: fe(0)> next
657     loading structure from address 0xfed97b90 (offset 97168)
658           callback_state_entry_header = {
659                   magic = 0x54637281
660                   len = 104
661                   nCBs = 1
662           }
663           FEDiskEntry = {
664                   fe = {
665                           vnode = 46426
666                           unique = 125874
667                           volid = 537156174
668                           fnext = 8880
669                           ncbs = 1
670                           firstcb = 23232
671                           status = 0
672                   }
673                   index = 21352
674           }
675     fs state analyzer: fe(1)> cb
676     fs state analyzer: fe(1):cb(0)> dump
677     loading structure from address 0xfed97bd4 (offset 97236)
678           CBDiskEntry = {
679                   cb = {
680                           cnext = 0
681                           fhead = 21352
682                           thead = 103
683                           status = 1
684                           hhead = 382
685                           tprev = 23751
686                           tnext = 22772
687                           hprev = 23751
688                           hnext = 7824
689                   }
690                   index = 23232
691           }