From: Richard Wareing <rwareing@fb.com>
To: linux-xfs@vger.kernel.org
Cc: Richard Wareing <rwareing@fb.com>,
david@fromorbit.com, darrick.wong@oracle.com
Subject: [PATCH v2 0/3] XFS real-time device tweaks
Date: Sat, 2 Sep 2017 15:41:42 -0700 [thread overview]
Message-ID: <20170902224145.1291030-1-rwareing@fb.com> (raw)
Taking another run at this based on all the feedback (much appreciated).
- Replaced rtdefault with rtdisable, this yields similar operational
benefits when combined with the existing mkfs time setting of the inheritance
flag on the root directory. Allows temporary disabling of real-time allocation
without having to walk entire FS to remove flags (which could be time consuming).
I still don't think it's super obvious to an admin the real-time flag was put
there at mkfs time (vs. rtdefault being in mount flags), but this gets me
half of what I'm after.
- rtstatfs flag is removed, instead per Dave's suggestion we look for the
inheritance flag on the directory inode, if so we fill the statfs struct
with the real-time block info, otherwise data block info. Open to making
this behavior a flag if folks are worried it might be a jarring change
to folks used to the old behavior (i.e. data device info no matter what).
- rtfallocmin no changes, need to think more about this. Still a pretty big
fan of this option for reasons already stated; at least until a more elegant
solution such as preferred AGs (we'd need a tunable size for the "preferred"
AG, since our SSD partitions are a fraction of the size of a normal AG) can
be implemented. The only other idea I have is to make a new ioctl e.g.
"norealtime", which causes the RT bits to stay cleared regardless of
inheritance bits on the containing directory. This would allowing the
"steering" of files to the data device (e.g. SSD); this is probably a safer
design than defaulting to SSD and steering to the HDD via the realtime ioctl.
Richard Wareing (3):
fs/xfs: Add rtdisable option
fs/xfs: Add real-time device support to statfs
fs/xfs: Add rtfallocmin mount option
fs/xfs/xfs_file.c | 16 ++++++++++++++++
fs/xfs/xfs_inode.c | 6 ++++--
fs/xfs/xfs_ioctl.c | 7 +++++--
fs/xfs/xfs_mount.h | 2 ++
fs/xfs/xfs_super.c | 33 ++++++++++++++++++++++++++++++++-
5 files changed, 59 insertions(+), 5 deletions(-)
--
2.9.3
next reply other threads:[~2017-09-02 22:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-02 22:41 Richard Wareing [this message]
2017-09-02 22:41 ` [PATCH v2 1/3] fs/xfs: Add rtdisable option Richard Wareing
2017-09-02 22:41 ` [PATCH v2 2/3] fs/xfs: Add real-time device support to statfs Richard Wareing
2017-09-03 8:49 ` Christoph Hellwig
2017-09-02 22:41 ` [PATCH v2 3/3] fs/xfs: Add rtfallocmin mount option Richard Wareing
2017-09-03 8:50 ` Christoph Hellwig
2017-09-03 22:04 ` Richard Wareing
2017-09-03 8:56 ` [PATCH v2 0/3] XFS real-time device tweaks Christoph Hellwig
2017-09-03 22:02 ` Richard Wareing
2017-09-06 3:44 ` Dave Chinner
2017-09-06 6:54 ` Richard Wareing
2017-09-06 11:19 ` Dave Chinner
2017-09-06 11:43 ` Brian Foster
2017-09-06 12:12 ` Dave Chinner
2017-09-06 12:49 ` Brian Foster
2017-09-06 23:29 ` Dave Chinner
2017-09-07 11:58 ` Brian Foster
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=20170902224145.1291030-1-rwareing@fb.com \
--to=rwareing@fb.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.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