From: Christoph Hellwig <hch@infradead.org>
To: Richard Wareing <rwareing@fb.com>
Cc: linux-xfs@vger.kernel.org, david@fromorbit.com, darrick.wong@oracle.com
Subject: Re: [PATCH v2 0/3] XFS real-time device tweaks
Date: Sun, 3 Sep 2017 01:56:02 -0700 [thread overview]
Message-ID: <20170903085602.GF32385@infradead.org> (raw)
In-Reply-To: <20170902224145.1291030-1-rwareing@fb.com>
On Sat, Sep 02, 2017 at 03:41:42PM -0700, Richard Wareing wrote:
> - 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.
I still don't understand this option. What is the use case of
dynamically switching on/off these default to the rt device?
> - 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.
Jens just added a nice new fcntl to declare the life time of write
streams (and in theory can add other I/O hints).
How about a a mount option that moves all I/O with a given hint
to the RT device? E.g. rt=longlife would direct I/O on a file
with an rw hint of RWH_WRITE_LIFE_LONG or RWH_WRITE_LIFE_EXTREME to the
RT subvolume as long as there aren't any previous extents.
next prev parent reply other threads:[~2017-09-03 8:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-02 22:41 [PATCH v2 0/3] XFS real-time device tweaks Richard Wareing
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 ` Christoph Hellwig [this message]
2017-09-03 22:02 ` [PATCH v2 0/3] XFS real-time device tweaks 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=20170903085602.GF32385@infradead.org \
--to=hch@infradead.org \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=rwareing@fb.com \
/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.