From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 1/1] Use real FS block size in fallocate05
Date: Fri, 29 Nov 2019 11:17:28 -0500 (EST) [thread overview]
Message-ID: <1057914729.14405454.1575044248773.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <0e1a3d0e-a154-8469-6e04-a954740a4a61@suse.cz>
----- Original Message -----
> On 11/29/19 1:01 PM, Jan Stancek wrote:
> >> + tst_res(TCONF | TTERRNO, "fallocate() not supported");
> >
> > tst_brk would make more sense here. If we fail here we can end the test.
>
> No. tst_brk() will terminate the whole test on the first usual test case
> (Ext2) and skip all the other file systems that do support fallocate().
It shouldn't. tst_brk() does call exit() for test process, but
.all_filesystems spawns new process for each fs.
If I add:
tst_brk(TCONF, "STOP");
to run(), I get STOP for each fs:
$ sudo ./fallocate05 2>&1 | grep STOP
fallocate05.c:30: CONF: STOP
fallocate05.c:30: CONF: STOP
fallocate05.c:30: CONF: STOP
fallocate05.c:30: CONF: STOP
fallocate05.c:30: CONF: STOP
fallocate05.c:30: CONF: STOP
>
> > I don't understand why there is need to find minimum value that can
> > satisfy this check. It looks like we are testing tst_fill_fs() more
> > than fallocate().
> >
> > In other words, what is wrong with current test? Is the problem that
> > FALLOCATE_SIZE (1M) is not aligned on all platforms? Or is the test
> > invalid with FALLOCATE_SIZE that big? Or both?
>
> I don't like to blindly rely on the assumption that block size is always
> a power of 2 and smaller than some magic number. Getting the real block
> size is trivial. The only real question is how many free blocks do we
> allow on a "full" file system in our tests. 1MB is just 16 blocks on
> PPC64 so the magic number isn't particularly big anyway.
OK, let's assume 16 is enough. Can we use that value also for ENOSPC check?
TEST(fallocate(fd, 0, bufsize, 2 * statbuf.st_blksize));
next prev parent reply other threads:[~2019-11-29 16:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-28 9:36 [LTP] [PATCH 0/1] Use real FS block size in fallocate05 Martin Doucha
2019-11-28 9:36 ` [LTP] [PATCH 1/1] " Martin Doucha
2019-11-28 17:47 ` Petr Vorel
2019-11-29 9:54 ` Martin Doucha
2019-11-29 12:01 ` Jan Stancek
2019-11-29 15:25 ` Martin Doucha
2019-11-29 16:17 ` Jan Stancek [this message]
2019-12-04 10:38 ` Martin Doucha
2019-12-13 13:40 ` Cyril Hrubis
2019-12-17 13:17 ` [LTP] [PATCH v2] " Martin Doucha
2019-12-17 21:02 ` Jan Stancek
2019-12-18 9:09 ` Martin Doucha
2019-12-18 10:01 ` Martin Doucha
2019-12-18 10:07 ` Jan Stancek
2019-12-18 13:15 ` [LTP] [PATCH v3] " Martin Doucha
2020-01-02 10:01 ` Jan Stancek
2020-01-07 15:21 ` Cyril Hrubis
2020-01-07 15:50 ` Martin Doucha
2020-01-13 12:16 ` Martin Doucha
2020-01-13 13:16 ` Qu WenRuo
2020-01-13 13:25 ` Martin Doucha
2020-01-13 13:30 ` Qu WenRuo
2020-01-07 16:09 ` Martin Doucha
2020-01-07 16:29 ` Cyril Hrubis
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=1057914729.14405454.1575044248773.JavaMail.zimbra@redhat.com \
--to=jstancek@redhat.com \
--cc=ltp@lists.linux.it \
/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