[LTP] [PATCH v2] kernel/device-drivers/zram/zram01.sh : don't fill from /dev/zero

[Ian Wienand]

On Wed, Sep 13, 2023 at 03:35:18PM +0100, Richard Palethorpe wrote:
> I would suggest just using sync, but Petr originally suggested using a
> wait loop. Then reported that the bug was still reproducible with the
> loop:
> 
> https://lore.kernel.org/linux-block/Y3s+Czg8sBsGYO+1@pevik/
> 
> Then said it wasn't reproducible. The problem is that if using a loop
> doesn't solve it then possibly the VFAT meta-data doesn't get written to
> disk in the absence of any pressure.
> 
> So instead I'd suggest resurrecting Petr's original patch or at least
> his approach. If we merge that and still see failures then maybe it's
> worth investigating more with tracing/debugging.

I do not think the original patch [1] is the correct solution in light
of the further investigation that has happened after it was proposed.

[2] is about the clearest explaination I can come up with, other than
the patch description and comments added in the v2 patch [3].  I am of
the opinion that to be useful these tests need to explicitly make sure
they are not just writing data that can be de-duplicated.  I do not
believe the the intent of these tests was to have the only data
managed by the disk a very small amount of file-system metadata.

Sorry to sound like a broken record, but I spent some time
investigating the paths taken with [2] and confirming the stats that
were coming out were not due to some kernel issue, but it really was
that the backing area had no pages allocated to it at all.

Looping on a sync might make the test pass in more cases, but I hope
we can agree the idea is to make the test better, not just pass so we
can continue to ignore it.

-i

[1] https://lore.kernel.org/linux-block/20221107191136.18048-2-pvorel@suse.cz/
[2] https://lore.kernel.org/linux-block/ZNB2kORYiKdl3vSq@fedora19.localdomain/
[3] https://lore.kernel.org/ltp/ZPpOuK9lyWr2wZWI@fedora19.localdomain/T/#m1e037003252012ac115e57285a926db77380897f