## frack

#### OS/161 Reference Manual

### Name

frack - file system crack

### Synopsis

`/testbin/frack` `list`
`/testbin/frack` `do` workload [arg]
`/testbin/frack` `check` workload [arg]

### Description

`frack` is a general-purpose file system checker. It has a number of workloads built into it (currently 58, some of which are families of related workloads), each of which can be run in either `do` mode or `check` mode.

In `do` mode, `frack` executes the chosen workload against the file system.

In `check` mode, `frack` executes the chosen workload against an internal model of a file system, and builds a representation of all the successive states the file system reaches. Then it inspects the file system it is run on and matches its state against this representation. It finds the closest matching state, and then prints out the discrepancies it finds between that state and what it sees.

Note that the `check` mode expects that the `do` mode was run on an empty (newly formatted) file system volume. Otherwise, any other stuff on the volume will appear as a discrepancy and may cause the state matching algorithm to fail.

The intended use is for testing file system recovery: run a workload in `do` mode, crash during the workload (e.g. using the System/161 doom counter), run file system recovery, then run the same workload in `check` mode. Ideally, the `check` mode run will find the resulting on-disk state after recovery to exactly match some valid state the workload reached. In practice, some forms of discrepancy are often considered acceptable; your course staff should give you guidance on what you are and are not required to handle.

Note that you probably want to get your recovery code to the point where it reliably produces a valid, self-consistent volume that sfsck accepts before worrying about whether the `frack check` phase passes.

`frack` can also be used for testing the general correctness of a file system, such as by running the `do` mode of a workload to completion and then immediately (or after shutting down cleanly and rebooting) running in `check` mode.

Use `frack list` to see the available workloads. Some workloads take arguments; size arguments should be one of the keywords `small`, `medium`, or `large`, reflecting the size of the test file(s). Seed arguments are integer random seeds from 0 to 231-1.

Some workloads contain an explicit `sync`; generally these are meant to be crashed after, not before (or during) the sync call.

### Requirements

`frack` uses the following system calls:

- open
- fstat
- ftruncate
- lseek
- getdirentry
- read
- write
- close
- link
- remove
- chdir
- mkdir
- rmdir
- rename
- sync
- _exit

but note that it is intended to be able to exercise all the file-system-related calls and its exact requirements are workload-dependent.

`frack` is most useful for testing file system recovery, by intentionally crashing during workload runs. But it is also useful for checking general correctness of a file system.

### Bugs

Currently, none of the specific workloads are documented.