From: "Darrick J. Wong" <djwong@kernel.org>
To: David Disseldorp <ddiss@suse.de>
Cc: Dave Chinner <david@fromorbit.com>, fstests@vger.kernel.org
Subject: Re: [PATCH 1/3] more python dependence. was: populate: fix horrible performance due to excessive forking
Date: Thu, 12 Jan 2023 09:07:56 -0800 [thread overview]
Message-ID: <Y8A+bGITjQo1p3rg@magnolia> (raw)
In-Reply-To: <20230112112458.4b024930@echidna.fritz.box>
On Thu, Jan 12, 2023 at 11:24:58AM +0100, David Disseldorp wrote:
> Hi Darrick,
>
> On Wed, 11 Jan 2023 17:58:17 -0800, Darrick J. Wong wrote:
>
> > > (removexattr looks like a pain in perl though...)
> > >
> > > Anyway it's late now, I'll look at the diff tomorrow.
> >
> > ...or thursday now, since I decided to reply to the online fsck design
> > doc review comments, which took most of the workday. I managed to bang
> > out a python script (perl doesn't support setxattr!) that cut the xattr
> > overhead down to nearly zero.
>
> IIUC we currently only depend on python for the fio perf tests and
> btrfs/154 . My preference would be to not see it spread further
I don't appreciate your dismissal of the patch before I've even posted
it!
The fstests README clearly lists python3 as a dependency. Argument
parsing and xattr calls are provided by the base python3 runtime. No
third party libraries are required for this new program, and if they
were, they'd be added to the README.
> (especially if it's just to shave off a little runtime), mostly because
> it's a pain for dependency tracking.
> Perhaps you could use perl's syscall(SYS_fsetxattr(), ...)? Well, that or
Raw system calls are a terrible idea for maintainability. You'd
*seriously* rather I open-code the glibc xattr wrappers and make the
fstests community maintain that for the sake of your preference?
> rewrite it again in awk ;-P
WTAF?
--D
> Cheers, David
next prev parent reply other threads:[~2023-01-12 17:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-10 22:49 [PATCH 0/3] fstests: filesystem population fixes Dave Chinner
2023-01-10 22:49 ` [PATCH 1/3] populate: fix horrible performance due to excessive forking Dave Chinner
2023-01-11 6:02 ` Darrick J. Wong
2023-01-12 1:58 ` Darrick J. Wong
2023-01-12 10:24 ` [PATCH 1/3] more python dependence. was: " David Disseldorp
2023-01-12 17:07 ` Darrick J. Wong [this message]
2023-01-12 20:23 ` David Disseldorp
2023-01-12 20:42 ` Zorro Lang
2023-01-15 18:33 ` Darrick J. Wong
2023-01-10 22:49 ` [PATCH 2/3] populate: ensure btree directories are created reliably Dave Chinner
2023-01-11 5:47 ` Darrick J. Wong
2023-01-12 5:42 ` Gao Xiang
2023-01-10 22:49 ` [PATCH 3/3] xfs/294: performance is unreasonably slow Dave Chinner
2023-01-11 20:29 ` David Disseldorp
2023-01-12 8:39 ` Zorro Lang
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=Y8A+bGITjQo1p3rg@magnolia \
--to=djwong@kernel.org \
--cc=david@fromorbit.com \
--cc=ddiss@suse.de \
--cc=fstests@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.