From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] generic/466: be more precise about which block sizes to use
Date: Tue, 2 Jan 2018 12:36:50 -0800 [thread overview]
Message-ID: <20180102203650.GC5146@magnolia> (raw)
In-Reply-To: <20171231184508.GA29994@thunk.org>
On Sun, Dec 31, 2017 at 01:45:08PM -0500, Theodore Ts'o wrote:
> On Wed, Dec 13, 2017 at 09:36:29AM -0800, Darrick J. Wong wrote:
> > > + get_page_size
> > > + ;;
> > > + *)
> > > + echo 512
> >
> > FWIW XFS' minimum block size is 1k for v5 filesystems, though you can't
> > really tell until you run mkfs.xfs -N.
>
> Ok, but I assume we should keep this at 512 since it could be a v4
> file systems that are being tested?
That depends on whether this function returns the smallest blocksize
guaranteed to pass mkfs given the current set of options or the
theoretical smallest blocksize supported by that fs given the right set
of options. IOWs, if this is a v5 fs being tested, then "mkfs.xfs -b
size=$(_fs_min_blocksize) -m crc=1" will fail.
> > > +_fs_max_blocksize()
> > > +{
> > > + get_page_size
> >
> > Also, one can run xfstests against a fuse2fs-mounted 64k-block ext4 fs.
>
> Really? Does mmap work on a fuse2fs-mounted 64k-block ext4 file system?
Yes:
# uname -a
Linux magnolia 4.14.8-67-magnolia #2 SMP PREEMPT Fri Dec 22 17:23:52 PST 2017 x86_64 x86_64 x86_64 GNU/Linux
# truncate -s 1g /tmp/a
# mkfs.ext4 -b 65536 -F /tmp/a
...
# fuse2fs /tmp/a /mnt
/tmp/a: Writing to the journal is not supported.
# fallocate -l 128k /mnt/a
# xfs_io -c 'mmap -rw 0 128k' -c 'mwrite -S 0x58 0 6144' /mnt/a
# od -tx1 -Ad -c /mnt/a
0000000 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58
X X X X X X X X X X X X X X X X
*
0006144 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0131072
> I suppose can just force the block size to be 64k for fuse2fs,
> although I don't think the using some file system like ext4 for
> fuse2fs testing isn't going to work right now anyway, yes?
I haven't tried it in some time, but the last time I ran xfstests
against fuse2fs it more or less worked (modulo all the fancy fallocate
stuff that it doesn't support).
--D
>
> - Ted
next prev parent reply other threads:[~2018-01-02 20:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-11 17:27 [PATCH] generic/466: be more precise about which block sizes to use Theodore Ts'o
2017-12-13 17:36 ` Darrick J. Wong
2017-12-31 18:45 ` Theodore Ts'o
2018-01-02 20:36 ` Darrick J. Wong [this message]
2018-01-05 2:12 ` Darrick J. Wong
2018-01-05 3:28 ` Theodore Ts'o
2018-01-07 15:24 ` Eryu Guan
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=20180102203650.GC5146@magnolia \
--to=darrick.wong@oracle.com \
--cc=fstests@vger.kernel.org \
--cc=tytso@mit.edu \
/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