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

[Ian Wienand <iwienand@redhat.com>]

On Thu, Sep 07, 2023 at 12:18:38PM +0200, Martin Doucha wrote:
> On 07. 09. 23 8:46, Ian Wienand wrote:
> > I don't think adding another test really helps.
> > 
> > I think the best course here is to fix zram01.sh to write enough
> > random data to stress the compression paths and further sync to make
> > it reliable.  This is what the patch proposes.
> > 
> > If there's some agreement that the investigation above is valid, we
> > could probably remove zram03.c.  It's not really doing anything
> > zram01.sh doesn't do and it is not really stressing anything either.
> 
> Please do not completely rewrite test scenarios to hide one failure due to
> filesystem specifics. If this is not a kernel bug, the correct way to deal
> with this is to disable testing on vfat in initialize_vars():
> 
> for fs in $(tst_supported_fs -s tmpfs,vfat); do

I don't think this is the correct way to deal with it.  I think that
you're probably referring to earlier mail where there was a suggestion
that this was a ppc64/vfat specific issue [1].  I was seeing this in a
different context, and I believe the zeros are explained by no data
actually being in the compressed buffers, as explained at [2].  Hence
I think we need to come to some conclusion on actually writing data
during testing.

-i

[1] https://lore.kernel.org/lkml/3ac740c0-954b-5e68-b413-0adc7bc5a2b5@suse.cz/#t
[2] https://lore.kernel.org/lkml/ZNB2kORYiKdl3vSq@fedora19.localdomain/


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp