linux-kernel - running xfstests on tmpfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 26 Nov 2020 13:49:17 -0800 (PST)
From:   Hugh Dickins <hughd@...gle.com>
To:     Matthew Wilcox <willy@...radead.org>
cc:     Hugh Dickins <hughd@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jan Kara <jack@...e.cz>,
        William Kucharski <william.kucharski@...cle.com>,
        Linux-FSDevel <linux-fsdevel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>, Christoph Hellwig <hch@....de>,
        Johannes Weiner <hannes@...xchg.org>,
        Yang Shi <yang.shi@...ux.alibaba.com>, dchinner@...hat.com,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: running xfstests on tmpfs

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
Download attachment "xfstests-tmpfs.tar" of type "APPLICATION/x-tar" (20480 bytes)