From: Josef Bacik <josef@toxicpanda.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Josef Bacik <josef@toxicpanda.com>,
Dave Chinner <david@fromorbit.com>,
linux-fsdevel@vger.kernel.org, kernel-team@fb.com,
linux-btrfs@vger.kernel.org, linux-block@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework
Date: Mon, 9 Oct 2017 08:54:16 -0400 [thread overview]
Message-ID: <20171009125415.wrfd5rp5zlf4qsgm@destiny> (raw)
In-Reply-To: <20171009034335.pwehn4kz3cwjy6o7@thunk.org>
On Sun, Oct 08, 2017 at 11:43:35PM -0400, Theodore Ts'o wrote:
> On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote:
> >
> > Probably should have led with that shouldn't I have? There's nothing keeping me
> > from doing it, but I didn't want to try and shoehorn in a python thing into
> > fstests. I need python to do the sqlite and the json parsing to dump into the
> > sqlite database.
>
> What version of python are you using? From inspection it looks like
> some variant of python 3.x (you're using print as a function w/o using
> "from __future import print_function") but it's not immediately
> obvious from the top-level fsperf shell script what version of python
> your scripts are dependant upon.
>
> This could potentially be a bit of a portability issue across various
> distributions --- RHEL doesn't ship with Python 3.x at all, and on
> Debian you need to use python3 to get python 3.x, since
> /usr/bin/python still points at Python 2.7 by default. So I could see
> this as a potential issue for xfstests.
>
> I'm currently using Python 2.7 in my wrapper scripts for, among other
> things, to parse xUnit XML format and create nice summaries like this:
>
> ext4/4k: 337 tests, 6 failures, 21 skipped, 3814 seconds
> Failures: generic/232 generic/233 generic/361 generic/388
> generic/451 generic/459
>
> So I'm not opposed to python, but I will note that if you are using
> modules from the Python Package Index, and they are modules which are
> not packaged by your distribution (so you're using pip or easy_install
> to pull them off the network), it does make doing hermetic builds from
> trusted sources to be a bit trickier.
>
> If you have a secops team who wants to know the provenance of software
> which get thrown in production data centers (and automated downloading
> from random external sources w/o any code review makes them break out
> in hives), use of PyPI adds a new wrinkle. It's not impossible to
> solve, by any means, but it's something to consider.
>
I purposefully used as little as possible, just json and sqlite, and I tried to
use as little python3 isms as possible. Any rpm based systems should have these
libraries already installed, I agree that using any of the PyPI stuff is a pain
and is a non-starter for me as I want to make it as easy as possible to get
running.
Where do you fall on the including it in xfstests question? I expect that the
perf stuff would be run more as maintainers put their pull requests together to
make sure things haven't regressed. To that end I was going to wire up
xfstests-bld to run this as well. Whatever you and Dave prefer is what I'll do,
I'll use it wherever it ends up so you two are the ones that get to decide.
Thanks,
Josef
next prev parent reply other threads:[~2017-10-09 12:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-06 21:09 [ANNOUNCE] fsperf: a simple fs/block performance testing framework Josef Bacik
2017-10-09 0:51 ` Dave Chinner
2017-10-09 2:25 ` Josef Bacik
2017-10-09 3:43 ` Theodore Ts'o
2017-10-09 12:54 ` Josef Bacik [this message]
2017-10-09 15:14 ` Theodore Ts'o
2017-10-09 5:17 ` Dave Chinner
2017-10-09 6:54 ` Eryu Guan
2017-10-09 12:52 ` Theodore Ts'o
2017-10-09 13:00 ` Josef Bacik
2017-10-09 21:09 ` Dave Chinner
2017-10-09 21:15 ` Josef Bacik
2017-10-10 9:00 ` Mel Gorman
2017-10-09 14:40 ` David Sterba
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=20171009125415.wrfd5rp5zlf4qsgm@destiny \
--to=josef@toxicpanda.com \
--cc=david@fromorbit.com \
--cc=kernel-team@fb.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@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