[LTP] [PATCH 2/2] fill_fs: Ensure written data is not easily compressed

[Richard Palethorpe]

Hello,

Cyril Hrubis <chrubis@suse.cz> writes:

> Hi!
>> What are we trying to do though, simply fill the device to test the
>> ENOSPC condition or some kind of poor man's fuzzing?
>
> The test is supposed to test what happens when filesystem is altmost
> full and being written to, which may trigger all kinds of corner cases.
> In that sense it makes sense to randomize the access patterns a bit so
> that we have higher chances of utilizing different code paths. But of
> course the question where should we stop in randomizing things and what
> makes sense and what does not.

I think there are multiple scenarious which are totally different.

For example, Redis uses an append only file (AOF) and IIRC you can
choose to batch writes for performance at the expense of data
integrity. It's common for the AOF to have it's own volume.

OTOH if we have a classic server with 1000s of daemons running, then we
can expect writes to happen in parallel and be random.

I'd be in favor of trying to test these things separately and to keep
each scenario as simple (and reproducible) as possible. I think mixing
together different access patterns is better handled by fuzzing.

-- 
Thank you,
Richard.