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

Ian Wienand iwienand@redhat.com
Tue Sep 12 03:03:01 CEST 2023


On Fri, Sep 08, 2023 at 11:21:47AM +0200, Martin Doucha wrote:
> On 08. 09. 23 0:29, Ian Wienand wrote:
> > 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.
> 
> Well then, did you see the failure on any other filesystem than vfat? I've
> read this whole e-mail thread again but there is no mention of which
> filesystems trigger this issue.
> 

I see this on vfat; the test stops after the failure.  But I think
focusing on the file-system is a red-herring in this case.  As
explained at [1] I think the problem is more that there's insufficient
data written due to the de-deuplication.  This probably exhibits most
easily on vfat if it's not doing something like writing superblocks in
other areas of the disk, etc.

> Alternatively, if kernel developers say that the caching behavior in zram is
> correct, then your v1 patch (adding sync) is the right solution.

I think this explains why it is the test, not the kernel behaviour,
that is causing the failure.

-i

[1] https://lore.kernel.org/linux-block/ZNB2kORYiKdl3vSq@fedora19.localdomain/#t



More information about the ltp mailing list