public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it, Martin Doucha <martin.doucha@suse.com>
Subject: Re: [LTP] TMPDIR minimal size requirement
Date: Tue, 6 Feb 2024 19:53:35 +0100	[thread overview]
Message-ID: <20240206185335.GA51648@pevik> (raw)
In-Reply-To: <20240201101603.GA78772@pevik>

> Hi all,

> recent LTP change 3626124a4 ("fallocate06: Increase test loop device size to
> 1GB") [1] increased requirement on TMPDIR size for syscalls. That hits the size
> of tmpfs we use in openSUSE Tumbleweed on /tmp. While we can workaround easily
> this in openQA framework we use for LTP testing (use TMPDIR=/var/tmp for
> fallocate06 or even for whole runtest syscalls), I wonder if we should have some
> LTP upstream fix.

FYI I see the problem also on fallocate05 on bcachefs, although here it might be
a bug in fallocate05 or in bcachefs, because the test somehow works with ENOTSUP
(there is a code before which checks on ENOTSUP). And I was not able to
reproduce it on similar VM outside of our openQA test framework, it could be our
bug in openQA runner as well.

Kind regards,
Petr

fallocate05.c:136: TPASS: write()
tst_test.c:1701: TINFO: === Testing on bcachefs ===
tst_test.c:1117: TINFO: Formatting /dev/loop0 with bcachefs opts='' extra opts=''
tst_test.c:1131: TINFO: Mounting /dev/loop0 to /tmp/LTP_falBnQfVp/mntpoint fstyp=bcachefs flags=0
tst_fill_fs.c:36: TINFO: Creating file mntpoint/file0 size 21710183
tst_fill_fs.c:36: TINFO: Creating file mntpoint/file1 size 8070086
tst_fill_fs.c:36: TINFO: Creating file mntpoint/file2 size 3971177
tst_fill_fs.c:36: TINFO: Creating file mntpoint/file3 size 36915315
tst_fill_fs.c:36: TINFO: Creating file mntpoint/file4 size 70310993
tst_fill_fs.c:36: TINFO: Creating file mntpoint/file5 size 4807935
tst_fill_fs.c:36: TINFO: Creating file mntpoint/file6 size 90739786
tst_fill_fs.c:36: TINFO: Creating file mntpoint/file7 size 76896492
tst_fill_fs.c:63: TINFO: write(): ENOSPC (28)
fallocate05.c:81: TPASS: write() wrote 131072 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:134: TFAIL: write(): ENOSPC (28)

> What comes to mi mind, we could use as TMPDIR default /var/tmp (only if it does
> not exists, we would fallback to /tmp). We could also warn against tmpfs use.
> Or at least document on README that although many tests need 300 MB for a block
> device, some tests require more and suggest to use /var/tmp.

> Also, Cyril asked for a patch with minimal device size per filesystem (IMHO
> still would be done). At least for Btrfs and XFS some people complains 300
> MB is not a real testing scenario, therefore if we implement it and use 1 GB
> e.g. for Btrfs and XFS we will hit limits on "low resource" devices.

> Kind regards,
> Petr

> [1] https://github.com/linux-test-project/ltp/commit/3626124a42adfe536af2abff63213fa1ccc63795

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

      reply	other threads:[~2024-02-06 18:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-01 10:16 [LTP] TMPDIR minimal size requirement Petr Vorel
2024-02-06 18:53 ` Petr Vorel [this message]

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=20240206185335.GA51648@pevik \
    --to=pvorel@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=martin.doucha@suse.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox