search

utsaslab / crashmonkey

CrashMonkey: tools for testing file-system reliability (OSDI 18)
Apache License 2.0
193 stars 31 forks source link

Put whether a bio is data or metadata in output log #53

Open ashmrtn opened 7 years ago

ashmrtn commented 7 years ago

17 and #48 brought in a log file that the failing tests are printed to. This log output contains the indices of the bios in the crash state, and the order they were written out to disk to to form the crash state. This list of indices should be augmented to show whether the bio was a metadata bio or a data bio.

Metadata bios will be denoted by the META flag in the bio itself. Data bios will not have that flag.

Since the amount of data stored in the test result object is minimal at this time, we will likely have to expand the member variable that contains the crash state index information. Expanding that to have <index, data> pairs should suffice.

Sample output for this change could look like/similar to the following:

Test #26 FAILED: file missing: test file has completely disappeared
   last checkpoint: 2
   crash state: 0 (M), 1 (D), 2 (D), 4 (D), 3 (D), 5 (M)
vijay03 commented 4 years ago

@ashmrtn @jayashreemohan29 Is this issue still relevant to CrashMonkey?

ashmrtn commented 4 years ago

From a technical perspective it is not required, though it may make debugging certain issues a little easier. The debugging help assumes that file systems properly set the meta flag for changes to their own metadata (I believe that's what this flag is supposed to represent, but I don't think I ever tracked down the actual definition of it).

All changes for this code would be in the userspace portion of CM, specifically focusing on the portion that tracks the test case's crash state.