[LTP] [RFC PATCH] fallocate05: increase the fallocate and defallocate size
Li Wang
liwang@redhat.com
Thu Sep 23 05:00:17 CEST 2021
On Thu, Sep 23, 2021 at 12:52 AM Ralph Siemsen <ralph.siemsen@linaro.org>
wrote:
> Hello,
>
> On Wed, Sep 22, 2021 at 04:32:45PM +0200, Cyril Hrubis wrote:
> >>
> >> That try one by one block after filling full of the FS because nobody
> knows
> >> when fails.
> >>
> >> But as you suggested we can do that as well for the previous allocation
> :).
> >>
> >> So, will you create a patch, or I do that tomorrow?
> >
> >I will not manage today. So either you do it or I can do it tomorrow
> >:-).
>
> I tried making a patch for this, which I can share. But after testing, I
> am still seeing OOM. Upon further inspection, it seems to be coming from
> tst_fill_fs() function, when operating on a tmpfs. I see the message:
>
> tst_test.c:903: TINFO: Limiting tmpfs size to 512MB
>
> However the machine only has 256MB total, of which at best 200 MB is
> available after kernel has booted.
>
> I'm now a bit confused as to why fallocate05 test worked previously.
> With release 20210524 version, I see the following:
>
Ah, I see, that because we set the tmpfs size from the commit below,
so you got 512MB tmpfs mount which is the root cause of OOM.
commit c305a53c561d8517340daa27790a3624f2491b72
Author: Li Wang <liwang@redhat.com>
Date: Fri Jul 9 15:52:03 2021 +0800
lib: limit the size of tmpfs in LTP
LTP mount and make use of the whole tmpfs of the test system,
generally, it's fine. But if a test (e.g fallocate06) try to
fill full in the filesystem, it takes too long to complete
testing on a large memory system.
This patch adds a new function limit_tmpfs_mount_size with
appending '-o size=xxM' to the mount options in prepare_device()
which helps limit the tmpfs mount size.
A simple way to verify my assumption, you can try:
--- a/testcases/kernel/syscalls/fallocate/fallocate05.c
+++ b/testcases/kernel/syscalls/fallocate/fallocate05.c
@@ -147,7 +147,7 @@ static void cleanup(void)
static struct tst_test test = {
.needs_root = 1,
.mount_device = 1,
- .dev_min_size = 512,
+ .dev_min_size = 64,
.mntpoint = MNTPOINT,
.all_filesystems = 1,
.setup = setup,
>
> tst_test.c:1379: TINFO: Testing on tmpfs
> tst_test.c:888: TINFO: Skipping mkfs for TMPFS filesystem
> tst_test.c:1311: TINFO: Timeout per run is 0h 15m 00s
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file0 size 21710183
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file1 size 8070086
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file2 size 3971177
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file3 size 36915315
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file4 size 70310993
> tst_fill_fs.c:59: TINFO: write(): ENOSPC (28)
> fallocate05.c:81: TPASS: write() wrote 65536 bytes
> fallocate05.c:102: TINFO: fallocate()d 0 extra blocks on full FS
> fallocate05.c:114: TPASS: fallocate() on full FS
> fallocate05.c:130: TPASS: fallocate(FALLOC_FL_PUNCH_HOLE |
> FALLOC_FL_KEEP_SIZE)
> fallocate05.c:136: TPASS: write()
>
> Whereas with the latest git version, it seems to create two more
> additional files, before OOM kicks in:
>
Before the above commit, LTP took the whole tmpfs of SUT,
so the test size depends on the real system situation.
We do the improvement because we don't want to use larger
tmpfs size on a Huge RAM machine. But seems we neglect small
systems :).
>
> tst_test.c:1421: TINFO: Testing on tmpfs
> tst_test.c:922: TINFO: Skipping mkfs for TMPFS filesystem
> tst_test.c:903: TINFO: Limiting tmpfs size to 512MB
> tst_test.c:1353: TINFO: Timeout per run is 0h 15m 00s
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file0 size 21710183
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file1 size 8070086
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file2 size 3971177
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file3 size 36915315
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file4 size 70310993
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file5 size 4807935
> tst_fill_fs.c:32: TINFO: Creating file mntpoint/file6 size 90739786
> <... OOM begins here ...>
>
> Any thoughts on what might be happening?
>
> Regards,
> Ralph
>
>
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210923/86148a93/attachment-0001.htm>
More information about the ltp
mailing list