From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: darrick.wong@oracle.com
Cc: linux-xfs@vger.kernel.org
Subject: [PATCH v2 0/6] xfs: scrub-related fixes
Date: Wed, 26 Jun 2019 13:46:33 -0700 [thread overview]
Message-ID: <156158199378.495944.4088787757066517679.stgit@magnolia> (raw)
Hi all,
I discovered by sampling xfs_scrub stack trace swith a flame graph that
the attr scrub code has a sizeable oversight -- the xattr scrub code
always allocates a zeroed 65K temporary buffer before locking the inode,
even if it then turns out that the inode does not have extended
attributes.
In addition to the pointless memory allocation, the scrub code itself is
careful to initialize whatever part of the memory buffer it's going to
use before reading the contents, which means that the memory clearing is
not only painful (it's 5% of the sample traces!) but totally pointless.
The first patch does more whack-a-mole cleanup of places where corrupt
ondisk directory metadata causes ASSERTs instead of -EFSCORRUPTED
returns.
The rest of the series first cleans up the open-coded pointer
calculations where the buffer is concerned, and then restructures the
code so to allocate the smallest size buffer needed and only just before
it's actually needed. The final patch disables buffer zeroing for
better performance.
If you're going to start using this mess, you probably ought to just
pull from my git trees, which are linked below.
This is an extraordinary way to destroy everything. Enjoy!
Comments and questions are, as always, welcome.
--D
kernel git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=attr-scrub-fixes
next reply other threads:[~2019-06-26 20:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-26 20:46 Darrick J. Wong [this message]
2019-06-26 20:46 ` [PATCH 1/6] xfs: remove more ondisk directory corruption asserts Darrick J. Wong
2019-07-05 14:49 ` Brian Foster
2019-07-05 17:03 ` Darrick J. Wong
2019-07-05 17:27 ` Brian Foster
2019-06-26 20:46 ` [PATCH 2/6] xfs: attribute scrub should use seen_enough to pass error values Darrick J. Wong
2019-07-05 14:49 ` Brian Foster
2019-07-05 16:46 ` Darrick J. Wong
2019-06-26 20:46 ` [PATCH 3/6] xfs: refactor extended attribute buffer pointer functions Darrick J. Wong
2019-07-05 14:52 ` Brian Foster
2019-06-26 20:46 ` [PATCH 4/6] xfs: refactor attr scrub memory allocation function Darrick J. Wong
2019-07-05 14:52 ` Brian Foster
2019-06-26 20:47 ` [PATCH 5/6] xfs: only allocate memory for scrubbing attributes when we need it Darrick J. Wong
2019-07-05 14:52 ` Brian Foster
2019-07-05 16:49 ` Darrick J. Wong
2019-06-26 20:47 ` [PATCH 6/6] xfs: online scrub needn't bother zeroing its temporary buffer Darrick J. Wong
2019-07-05 14:52 ` Brian Foster
2019-07-05 16:35 ` Darrick J. Wong
2019-07-05 17:26 ` Brian Foster
2019-07-05 17:57 ` Darrick J. Wong
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=156158199378.495944.4088787757066517679.stgit@magnolia \
--to=darrick.wong@oracle.com \
--cc=linux-xfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox