From: Petr Vorel <pvorel@suse.cz> To: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Martin Doucha <mdoucha@suse.cz>, Minchan Kim <minchan@kernel.org>, ltp@lists.linux.it, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Nitin Gupta <ngupta@vflare.org>, Jens Axboe <axboe@kernel.dk>, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>, Yang Xu <xuyang2018.jy@fujitsu.com> Subject: Re: [PATCH 0/1] Possible bug in zram on ppc64le on vfat Date: Mon, 21 Nov 2022 10:41:13 +0100 [thread overview] Message-ID: <Y3tHuWygsBqmmpwV@pevik> (raw) In-Reply-To: <Y22b3wWs2QfMjJHi@google.com> Hi Sergey, > On (22/11/10 15:29), Martin Doucha wrote: > > New version of LTP test zram01 found a sysfile issue with zram devices > > mounted using VFAT filesystem. When when all available space is filled, e.g. > > by `dd if=/dev/zero of=/mnt/zram0/file`, the corresponding sysfile > > /sys/block/zram0/mm_stat will report that the compressed data size on the > > device is 0 and total memory usage is also 0. LTP test zram01 uses these > > values to calculate compression ratio, which results in division by zero. > > The issue is specific to PPC64LE architecture and the VFAT filesystem. No > > other tested filesystem has this issue and I could not reproduce it on other > > archs (s390 not tested). The issue appears randomly about every 3 test runs > > on SLE-15SP2 and 15SP3 (kernel 5.3). It appears less frequently on SLE-12SP5 > > (kernel 4.12). Other SLE version were not tested with the new test version > > yet. The previous version of the test did not check the VFAT filesystem on > > zram devices. > Whoooaa... > > I've tried to debug the issue and collected some interesting data (all > > values come from zram device with 25M size limit and zstd compression > > algorithm): > > - mm_stat values are correct after mkfs.vfat: > > 65536 220 65536 26214400 65536 0 0 0 > > - mm_stat values stay correct after mount: > > 65536 220 65536 26214400 65536 0 0 0 > > - the bug is triggered by filling the filesystem to capacity (using dd): > > 4194304 0 0 26214400 327680 64 0 0 > Can you try using /dev/urandom for dd, not /dev/zero? > Do you still see zeroes in sysfs output or some random values? I'm not sure if Martin had time to rerun the test. I was not able to reproduce the problem any more on machine where the test was failing. But I'll have look into this during this week. Kind regards, Petr
WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz> To: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Jens Axboe <axboe@kernel.dk>, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>, linux-kselftest@vger.kernel.org, ltp@lists.linux.it Subject: Re: [LTP] [PATCH 0/1] Possible bug in zram on ppc64le on vfat Date: Mon, 21 Nov 2022 10:41:13 +0100 [thread overview] Message-ID: <Y3tHuWygsBqmmpwV@pevik> (raw) In-Reply-To: <Y22b3wWs2QfMjJHi@google.com> Hi Sergey, > On (22/11/10 15:29), Martin Doucha wrote: > > New version of LTP test zram01 found a sysfile issue with zram devices > > mounted using VFAT filesystem. When when all available space is filled, e.g. > > by `dd if=/dev/zero of=/mnt/zram0/file`, the corresponding sysfile > > /sys/block/zram0/mm_stat will report that the compressed data size on the > > device is 0 and total memory usage is also 0. LTP test zram01 uses these > > values to calculate compression ratio, which results in division by zero. > > The issue is specific to PPC64LE architecture and the VFAT filesystem. No > > other tested filesystem has this issue and I could not reproduce it on other > > archs (s390 not tested). The issue appears randomly about every 3 test runs > > on SLE-15SP2 and 15SP3 (kernel 5.3). It appears less frequently on SLE-12SP5 > > (kernel 4.12). Other SLE version were not tested with the new test version > > yet. The previous version of the test did not check the VFAT filesystem on > > zram devices. > Whoooaa... > > I've tried to debug the issue and collected some interesting data (all > > values come from zram device with 25M size limit and zstd compression > > algorithm): > > - mm_stat values are correct after mkfs.vfat: > > 65536 220 65536 26214400 65536 0 0 0 > > - mm_stat values stay correct after mount: > > 65536 220 65536 26214400 65536 0 0 0 > > - the bug is triggered by filling the filesystem to capacity (using dd): > > 4194304 0 0 26214400 327680 64 0 0 > Can you try using /dev/urandom for dd, not /dev/zero? > Do you still see zeroes in sysfs output or some random values? I'm not sure if Martin had time to rerun the test. I was not able to reproduce the problem any more on machine where the test was failing. But I'll have look into this during this week. Kind regards, Petr -- Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-11-21 9:41 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-07 19:11 [PATCH 0/1] Possible bug in zram on ppc64le on vfat Petr Vorel 2022-11-07 19:11 ` [LTP] " Petr Vorel 2022-11-07 19:11 ` [PATCH 1/1] zram01.sh: Workaround division by 0 on vfat on ppc64le Petr Vorel 2022-11-07 19:11 ` [LTP] " Petr Vorel 2022-11-21 7:14 ` Li Wang 2022-11-21 8:59 ` Petr Vorel 2022-11-21 8:59 ` Petr Vorel 2023-09-18 9:38 ` Richard Palethorpe 2022-11-07 21:25 ` [PATCH 0/1] Possible bug in zram on ppc64le on vfat Minchan Kim 2022-11-07 21:25 ` [LTP] " Minchan Kim 2022-11-07 21:47 ` Petr Vorel 2022-11-07 21:47 ` [LTP] " Petr Vorel 2022-11-07 22:42 ` Petr Vorel 2022-11-07 22:42 ` [LTP] " Petr Vorel 2022-11-08 1:05 ` Sergey Senozhatsky 2022-11-08 1:05 ` [LTP] " Sergey Senozhatsky 2022-11-09 22:08 ` Petr Vorel 2022-11-09 22:08 ` [LTP] " Petr Vorel 2022-11-10 23:04 ` Minchan Kim 2022-11-10 23:04 ` [LTP] " Minchan Kim 2022-11-11 9:29 ` Petr Vorel 2022-11-11 9:29 ` [LTP] " Petr Vorel 2022-11-10 14:29 ` Martin Doucha 2022-11-10 14:29 ` [LTP] " Martin Doucha 2022-11-11 0:48 ` Sergey Senozhatsky 2022-11-11 0:48 ` [LTP] " Sergey Senozhatsky 2022-11-21 9:41 ` Petr Vorel [this message] 2022-11-21 9:41 ` Petr Vorel 2022-11-22 14:56 ` Martin Doucha 2022-11-22 14:56 ` Martin Doucha 2022-11-22 15:07 ` Petr Vorel 2022-11-22 15:07 ` [LTP] " Petr Vorel 2022-11-29 4:38 ` Sergey Senozhatsky 2022-11-29 4:38 ` [LTP] " Sergey Senozhatsky 2023-05-02 15:23 ` Martin Doucha 2023-05-02 15:23 ` [LTP] " Martin Doucha 2022-11-11 9:18 ` Petr Vorel 2022-11-11 9:18 ` [LTP] " Petr Vorel 2023-08-04 6:37 ` Ian Wienand 2023-08-04 6:37 ` Ian Wienand 2023-08-07 4:44 ` Ian Wienand 2023-08-07 4:44 ` [LTP] " Ian Wienand 2023-08-07 5:19 ` Sergey Senozhatsky 2023-08-07 5:19 ` [LTP] " Sergey Senozhatsky
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Y3tHuWygsBqmmpwV@pevik \ --to=pvorel@suse.cz \ --cc=axboe@kernel.dk \ --cc=hirofumi@mail.parknet.co.jp \ --cc=linux-block@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=ltp@lists.linux.it \ --cc=mdoucha@suse.cz \ --cc=minchan@kernel.org \ --cc=ngupta@vflare.org \ --cc=senozhatsky@chromium.org \ --cc=xuyang2018.jy@fujitsu.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.