From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-f2fs-devel@lists.sourceforge.net, fstests@vger.kernel.org,
Eric Biggers <ebiggers@google.com>
Subject: Re: [PATCH] xfstests-bld: add f2fs support
Date: Fri, 18 Nov 2016 10:04:21 -0800 [thread overview]
Message-ID: <20161118180421.GA31226@jaegeuk> (raw)
In-Reply-To: <20161118162249.iu45dkdynxdaotq7@thunk.org>
On Fri, Nov 18, 2016 at 11:22:49AM -0500, Theodore Ts'o wrote:
> On Thu, Nov 17, 2016 at 09:11:13PM -0800, Jaegeuk Kim wrote:
> >
> > IIUC, I guess it'd be okay if VM installed that as a package. I tried to add
> > f2fs-tools repo likewise fio, I could't find /sbin/mkfs.f2fs, even if it was
> > installed into bld/sbin/. Instead, bld/sbin/* were copied into xfstests/bin/
> > in VM, which enables to execute mkfs.f2fs globally through $PATH.
>
> Ah, I see what you mean; I thought you were talking about your local
> f2fstools git repo, and not changes you've made to your local
> xfstests-bld repo.
>
> The reason why xfsprogs is installed in xfstests/bin is that
> historically, xfstests needed some of the xfsprogs tools (no matter
> what file system type you were testing), and the xfsprogs installed in
> Debian and Ubuntu was too old or didn't install all of the utilities
> that xfstests required.
>
> However, I have not tried to build the file system utilities for other
> file systems in xfstests-bld --- and this includes e2fsprogs. My goal
> is to allow xfstests-bld to support a large number of file systems,
> and it doesn't scale to build all file system utilities in
> xfstests-bld. Also, most of the time, the file system utilities tend
> to move at a slower pace, and the requirements for needing a newer
> file system utility than what is shipped in the distribution is rarer.
>
> I have sometimes built a newer version of e2fsprogs as a Debian
> package, and installed it into the VM. These days, what I tend to do
> when that's been necessary is to build a new Debian package for
> jessie-backports, and upload it to the jessie-backports repository, so
> everyone can use the same binary package.
>
> I guess I don't have any objections to allowing people to put locally
> compiled versions of the utilities in /root/xfstests/sbin and rely on
> the PATH to use that version in preference to the /sbin/mkfs.f2fs
> version of the utilities. As far as adding the ability to download
> and build local versions of f2fstools in the upstream xfstests-bld, I
> guess I could accept that so long as it's optional, and not turned on
> by default. The main issue here is that if i have a half dozen file
> system-specific utilities included in xfstests-bld, which were all
> enabled for download by default, it would increase the build time of
> xfstests-bld significantly, so it doesn't scale. I'd much prefer to
> see newer versions of the utilities (if necessary) in
> debian-backports.
Agreed to all of them. What I tried to set up actually was to test the latest
f2fs-tools in prior to release out. Anyway, I agree it'd be good to add an
option to select local fs utilities through config.custom to avoid the scaling
problem.
I realize that xfstests-bld is really great to test multiple kernel versions.
I guess it can be quite doable to test arm-based kernel as well, as I can see
cross compile environment.
Thank you for sharing this tool.
>
> Cheers,
>
> - Ted
------------------------------------------------------------------------------
next prev parent reply other threads:[~2016-11-18 18:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-17 19:52 [PATCH] xfstests-bld: add f2fs support Eric Biggers
2016-11-18 4:38 ` Jaegeuk Kim
2016-11-18 4:51 ` Theodore Ts'o
2016-11-18 5:11 ` Jaegeuk Kim
2016-11-18 16:22 ` Theodore Ts'o
2016-11-18 18:04 ` Jaegeuk Kim [this message]
2016-11-18 22:07 ` Theodore Ts'o
2016-12-08 3:22 ` Theodore Ts'o
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=20161118180421.GA31226@jaegeuk \
--to=jaegeuk@kernel.org \
--cc=ebiggers@google.com \
--cc=fstests@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--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;
as well as URLs for NNTP newsgroup(s).