From: Hugh Dickins <hughd@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>,
William Kucharski <william.kucharski@oracle.com>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>, Christoph Hellwig <hch@lst.de>,
Johannes Weiner <hannes@cmpxchg.org>,
Yang Shi <yang.shi@linux.alibaba.com>,
dchinner@redhat.com, linux-kernel <linux-kernel@vger.kernel.org>
Subject: running xfstests on tmpfs
Date: Thu, 26 Nov 2020 13:49:17 -0800 (PST) [thread overview]
Message-ID: <alpine.LSU.2.11.2011261248150.3256@eggly.anvils> (raw)
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1978 bytes --]
On Thu, 26 Nov 2020, Matthew Wilcox wrote:
>
> The good news is that I've sorted out the SCRATCH_DEV issue with
> running xfstests. The bad news is that (even on an unmodified kernel),
> generic/027 takes 19 hours to run. On xfs, it's 4 minutes. Any idea
> why it's so slow on tmpfs?
It's to slow you down, to give me a better chance of keeping up.
But seriously, I suppose I ought to hand over the four xfstests
patches I add: let me change the Subject and attach a tarfile of them.
The problem with generic/027, if I'm recalling aright, is that it
(not unreasonably) expects the inodes to be limited by filesystem size,
whereas tmpfs has independent size (or nr_blocks) and nr_inodes limits.
I keep a six-year-old patch to make generic/027 more reasonable; but
a month ago switched over to limiting my nr_inodes better. Maybe the
recent patch makes the six-year-old one unnecessary, but I've had
bigger fish to worry about than check into that.
The script I use to run xfstests on huge tmpfs says:
export FSTYP=tmpfs
export DISABLE_UDF_TEST=1
export TEST_DEV=tmpfs1:
export TEST_DIR=/xft
export SCRATCH_DEV=tmpfs2:
export SCRATCH_MNT=/mnt
export TMPFS_MOUNT_OPTIONS="-o size=1088M,nr_inodes=272K,huge=always"
# mkfs -t $FSTYP $TEST_DEV || exit $?
mount -t $FSTYP $TMPFS_MOUNT_OPTIONS $TEST_DEV $TEST_DIR || exit $?
# mkfs -t $FSTYP $SCRATCH_DEV || exit $?
# mount -t $FSTYP $SCRATCH_DEV $SCRATCH_DIR || exit $?
./check -b "$@" # typically "-g auto"
umount /xft /mnt 2>/dev/null
And the one for non-huge tmpfs is the same except for "huge=never".
There is then some repetition in mount options shown when running
the tests, but I've not spent time to clean that up.
I'm very pleased for you to run them differently,
so we may find different things :)
generic/080 does fail on tmpfs (no page_mkwrite), and about three
more also fail on huge tmpfs (perhaps hole/data reasons); some more
fail on other test machines, I can't give a full account at the moment.
Hugh
[-- Attachment #2: Type: APPLICATION/x-tar, Size: 20480 bytes --]
next reply other threads:[~2020-11-26 21:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-26 21:49 Hugh Dickins [this message]
2020-11-30 20:02 ` running xfstests on tmpfs Hugh Dickins
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=alpine.LSU.2.11.2011261248150.3256@eggly.anvils \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=dchinner@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=william.kucharski@oracle.com \
--cc=willy@infradead.org \
--cc=yang.shi@linux.alibaba.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;
as well as URLs for NNTP newsgroup(s).