From: Kevin Wolf <kwolf@redhat.com>
To: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, hreitz@redhat.com,
vsementsov@yandex-team.ru, pbonzini@redhat.com,
eesposit@redhat.com, den@virtuozzo.com
Subject: Re: [PATCH v3 2/3] iotests/298: add testcase for async writes with preallocation filter
Date: Mon, 5 Aug 2024 15:50:28 +0200 [thread overview]
Message-ID: <ZrDYpHLq4h5wwHRi@redhat.com> (raw)
In-Reply-To: <9b44493d-2955-4c8c-a6a3-367335cdb3e7@virtuozzo.com>
Am 05.08.2024 um 14:56 hat Andrey Drobyshev geschrieben:
> On 8/5/24 3:04 PM, Kevin Wolf wrote:
> > Am 16.07.2024 um 16:41 hat Andrey Drobyshev geschrieben:
> >> The testcase simply creates a 64G image with 1M clusters, generates a list
> >> of 1M aligned offsets and feeds aio_write commands with those offsets to
> >> qemu-io run with '--aio native --nocache'. Then we check the data
> >> written at each of the offsets. Before the previous commit this could
> >> result into a race within the preallocation filter which would zeroize
> >> some clusters after actually writing data to them.
> >>
> >> Note: the test doesn't fail in 100% cases as there's a race involved,
> >> but the failures are pretty consistent so it should be good enough for
> >> detecting the problem.
> >>
> >> Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> >
> > I left it running in a loop for a while, but couldn't reproduce the bug
> > with this test.
> >
>
> Hmmm, it seems to have stopped failing on my setup as well, no matter
> how I increase the number of requests. And it seems to be related to
> the interleaving 'write-zeroes' requests. My initial attempt was to
> cover the case described by Vladimir here:
> https://lists.nongnu.org/archive/html/qemu-block/2024-07/msg00415.html
> Maybe we just leave it and try reproducing the corruption with just
> regular write requests? At least with this version it seems to be
> failing pretty stably on my setup:
>
> > + def test_prealloc_async_writes(self):
> > + requests = 2048 # Number of write/read requests to feed to qemu-io
> > + total_clusters = 64 * 1024 # 64G / 1M
> > +
> > + offsets = random.sample(range(0, total_clusters), requests)
> > + aio_write_cmds = [f'aio_write -P 0xaa {off}M 1M' for off in offsets]
> > + read_cmds = [f'read -P 0xaa {off}M 1M' for off in offsets]
> > +
> > + proc = iotests.QemuIoInteractive('--aio', 'native', '--nocache',
> > + '--image-opts', drive_opts)
> > + for cmd in aio_write_cmds:
> > + proc.cmd(cmd)
> > + proc.close()
> > +
> > + proc = iotests.QemuIoInteractive('-f', iotests.imgfmt, disk)
> > + for cmd in read_cmds:
> > + out = proc.cmd(cmd)
> > + self.assertFalse('Pattern verification failed' in str(out))
> > + proc.close()
> > +
This doesn't seem to fail for me either. Neither on tmpfs nor in my home
directory (which is XFS on an encrypted LVM volume).
Are you using some more complicated setup than "./check -qcow2 298"?
Do you think we could use blkdebug to deterministically trigger the case
instead of trying to brute force it? If we can suspend the write_zeroes
request on the child node of preallocate, I think that's all we need to
reproduce the bug as described in the commit message of the fix.
Kevin
next prev parent reply other threads:[~2024-08-05 13:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-16 14:41 [PATCH v3 0/3] Fix data corruption within preallocation Andrey Drobyshev
2024-07-16 14:41 ` [PATCH v3 1/3] block: zero data data corruption using prealloc-filter Andrey Drobyshev
2024-07-18 15:51 ` Kevin Wolf
2024-07-18 15:52 ` Denis V. Lunev
2024-07-18 19:46 ` Denis V. Lunev
2024-08-05 11:59 ` Kevin Wolf
2024-08-05 12:13 ` Denis V. Lunev
2024-07-16 14:41 ` [PATCH v3 2/3] iotests/298: add testcase for async writes with preallocation filter Andrey Drobyshev
2024-08-05 12:04 ` Kevin Wolf
2024-08-05 12:56 ` Andrey Drobyshev
2024-08-05 13:50 ` Kevin Wolf [this message]
2024-07-16 14:41 ` [PATCH v3 3/3] scripts: add filev2p.py script for mapping virtual file offsets mapping Andrey Drobyshev
2024-08-05 12:29 ` Kevin Wolf
2024-08-05 13:02 ` Andrey Drobyshev
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=ZrDYpHLq4h5wwHRi@redhat.com \
--to=kwolf@redhat.com \
--cc=andrey.drobyshev@virtuozzo.com \
--cc=den@virtuozzo.com \
--cc=eesposit@redhat.com \
--cc=hreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@yandex-team.ru \
/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;
as well as URLs for NNTP newsgroup(s).