From: Brian Foster <bfoster@redhat.com>
To: linux-bcachefs@vger.kernel.org, linux-xfs@vger.kernel.org
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Subject: [PATCH RFC 0/3] xfs: nodataio mount option to skip data I/O
Date: Wed, 10 Apr 2024 10:09:53 -0400 [thread overview]
Message-ID: <20240410140956.1186563-1-bfoster@redhat.com> (raw)
Hi all,
bcachefs has a nodataio mount option that is used for isolated metadata
performance testing purposes. When enabled, it performs all metadata I/O
as normal and shortcuts data I/O by directly invoking bio completion.
Kent had asked for something similar for fs comparison purposes some
time ago and I put together a quick hack based around an iomap flag and
mount option for XFS.
I don't recall if I ever posted the initial version and Kent recently
asked about whether we'd want to consider merging something like this. I
think there are at least a couple things that probably need addressing
before that is a viable option.
One is that the mount option is kind of hacky in and of itself. Beyond
that, this mechanism provides a means for stale data exposure because
writes with nodataio mode enabled will operate as if writes were
completed normally (including unwritten extent conversion). Therefore, a
remount to !nodataio mode means we read off whatever was last written to
storage.
Kent mentioned that Eric (or somebody?) had floated the idea of a mkfs
time feature flag or some such to control nodataio mode. That would
avoid mount api changes in general and also disallow use of such
filesystems in a non-nodataio mode, so to me seems like the direction
bcachefs should go with its variant of this regardless.
Personally, I don't have much of an opinion on whether something like
this lands upstream or just remains as a local test hack for isolated
performance testing. The code is simple enough as it is and not really
worth the additional polishing for the latter, but I offered to at least
rebase and post for discussion. Thoughts, reviews, flames appreciated.
Brian
Brian Foster (3):
iomap: factor out a bio submission helper
iomap: add nosubmit flag to skip data I/O on iomap mapping
xfs: add nodataio mount option to skip all data I/O
fs/iomap/buffered-io.c | 37 ++++++++++++++++++++++++++++---------
fs/xfs/xfs_iomap.c | 3 +++
fs/xfs/xfs_mount.h | 2 ++
fs/xfs/xfs_super.c | 6 +++++-
include/linux/iomap.h | 1 +
5 files changed, 39 insertions(+), 10 deletions(-)
--
2.44.0
next reply other threads:[~2024-04-10 14:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-10 14:09 Brian Foster [this message]
2024-04-10 14:09 ` [PATCH RFC 1/3] iomap: factor out a bio submission helper Brian Foster
2024-04-10 14:09 ` [PATCH RFC 2/3] iomap: add nosubmit flag to skip data I/O on iomap mapping Brian Foster
2024-04-10 14:09 ` [PATCH RFC 3/3] xfs: add nodataio mount option to skip all data I/O Brian Foster
2024-04-10 16:17 ` [PATCH RFC 0/3] xfs: nodataio mount option to skip " Kent Overstreet
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=20240410140956.1186563-1-bfoster@redhat.com \
--to=bfoster@redhat.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-bcachefs@vger.kernel.org \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).