[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