Put real data into file systems before resizing: the test data
was randomly generated and is in pairs of files each a power-of-two and
power-of-two plus one bytes to hopefully catch block and frag issues.
Each test fills (nearly) the file system with test data. If shrinking,
it removes enough data so that the shrunken file system will be large enough
to accomodate the data. (It's done this way to hopefully ensure some or
most of the data will need to be moved when shrinking). The files are
then checked with MD5 against the known list. This particular method
was chosen to reduce the amount of data checked in while still retaining
reproducibility.
There are more tests to come; since resize_ffs(8) currently does not
support ffsv2 or byteswapped file systems, only a couple token expected-fail
test cases for those were added. Also, only 8:1 blocksize:fragsize
combinations are currently tested.