From: Richard Palethorpe <rpalethorpe@suse.de>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 2/2] fill_fs: Ensure written data is not easily compressed
Date: Thu, 08 Dec 2022 08:57:55 +0000 [thread overview]
Message-ID: <87o7seqlry.fsf@suse.de> (raw)
In-Reply-To: <Y4+Dx/K8sglGix0m@yuki>
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.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-12-08 9:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-06 11:53 [LTP] [PATCH 1/2] fs_fill: Add max_runtime = 60 Richard Palethorpe via ltp
2022-12-06 11:53 ` [LTP] [PATCH 2/2] fill_fs: Ensure written data is not easily compressed Richard Palethorpe via ltp
2022-12-06 13:33 ` Cyril Hrubis
2022-12-06 15:22 ` Richard Palethorpe
2022-12-06 16:15 ` Cyril Hrubis
2022-12-06 16:30 ` Richard Palethorpe
2022-12-06 18:02 ` Cyril Hrubis
2022-12-08 8:57 ` Richard Palethorpe [this message]
2022-12-09 15:28 ` Cyril Hrubis
2022-12-06 15:33 ` [LTP] [PATCH 1/2] fs_fill: Add max_runtime = 60 Petr Vorel
2022-12-08 2:39 ` Li Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o7seqlry.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox