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

[Richard Palethorpe <rpalethorpe@suse.de>]

Hello,

Ian Wienand <iwienand@redhat.com> writes:

> 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

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.

-- 
Thank you,
Richard.

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