All of lore.kernel.org
 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 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.