On 21/08/2025 09:42, Ojaswin Mujoo wrote:
On Wed, Aug 13, 2025 at 02:39:40PM +0100, John Garry wrote:
On 10/08/2025 14:41, Ojaswin Mujoo wrote:
This adds atomic write test using fio based on it's crc check verifier.
fio adds a crc for each data block. If the underlying device supports
atomic write then it is guaranteed that we will never have a mix data from
two threads writing on the same physical block.
Avoid doing overlapping parallel atomic writes because it might give
unexpected results. Use offset_increment=, size= fio options to achieve
this behavior.
You are not really describing what the test does.
In the first paragraph, you state what fio verify function does and then
describe what RWF_ATOMIC means when we only use HW support, i.e. serialises.
In the second you mention that we guarantee no inter-thread overlapping
writes.
Got it John, I will add better commit messages for the fio tests.
From a glance at the code below, in this test each thread writes to a
separate part of the file and then verifies no crc corruption. But even with
atomic=0, I would expect no corruption here.
Right, this is mostly a stress test that is ensuring that all the new
atomic write code paths are not causing anything to break or
introducing any regressions. This should pass with both atomic or non
atomic writes but by using RWF_ATOMIC we excercise the atomic specific
code paths, improving the code coverage.
I am not sure really how much value this has. At least it should be
documented what we are doing here and what value there is in this test.
Thanks,
John
