fsstress: consistently index the ops array by OP_ type
authorDarrick J. Wong <djwong@kernel.org>
Wed, 8 Dec 2021 16:45:18 +0000 (08:45 -0800)
committerEryu Guan <guaneryu@gmail.com>
Sun, 12 Dec 2021 14:24:16 +0000 (22:24 +0800)
commit160a3b4b4477cf81632431ac8e17c8e03fdeede7
treef0c0a0bbe19abe6ecfefc6889b37e9b2f9607435
parentee78726548e0a0b808a340ef2e4097abea53952b
fsstress: consistently index the ops array by OP_ type

A mismerge during a git rebase some time ago broke fsstress in my
development tree, because it added OP_XCHGRANGE into the opt_y typedef
definition at a different offset than the actual entry in the ops array.
This broke the relationship ops[i].op == i.

Since most of fsstress.c blindly assumes that it's ok to index the ops
array by OP_ type, this off-by-one error meant that when I created an
fstest with "-f unlink=1", it actually set the frequency of the adjacent
operation (unresvsp) to 1.  I didn't notice this until I started to
investigate how a filesystem created with "-z -f creat=4 -f unlink=4"
could end up with 1.8 million files after 30 seconds.

Eliminate the possibility for future screwups like this by using indexed
array initializers.  This enables us to remove the separate op field in
struct opdesc, for a minor savings of memory footprint and reduction in
footgun opportunity.

While we're at it, reformat the ops table to be more pleasing to the
eye.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
ltp/fsstress.c