From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Richard Wareing <rwareing@fb.com>,
linux-xfs@vger.kernel.org,
Anthony Iliopoulos <ailiopoulos@suse.de>
Subject: Re: Modern uses of CONFIG_XFS_RT
Date: Wed, 19 Feb 2020 09:09:45 -0800 [thread overview]
Message-ID: <20200219170945.GN9506@magnolia> (raw)
In-Reply-To: <20200219143824.GR11244@42.do-not-panic.com>
On Wed, Feb 19, 2020 at 02:38:24PM +0000, Luis Chamberlain wrote:
> On Wed, Feb 19, 2020 at 03:32:27PM +0100, Carlos Maiolino wrote:
> > On Wed, Feb 19, 2020 at 01:57:15PM +0000, Luis Chamberlain wrote:
> > > I hear some folks still use CONFIG_XFS_RT, I was curious what was the
> > > actual modern typical use case for it. I thought this was somewhat
> > > realted to DAX use but upon a quick code inspection I see direct
> > > realtionship.
> >
> > Hm, not sure if there is any other use other than it's original purpose of
> > reducing latency jitters. Also XFS_RT dates way back from the day DAX was even a
> > thing. But anyway, I don't have much experience using XFS_RT by myself, and I
> > probably raised more questions than answers to yours :P
>
> What about another question, this would certainly drive the users out of
> the corners: can we remove it upstream?
My DVR and TV still use it to record video data.
I've also been pushing the realtime volume for persistent memory devices
because you can guarantee that all the expensive pmem gets used for data
storage, that the extents will always be perfectly aligned to large page
sizes, and that fs metadata will never defeat that alignment guarantee.
(Granted now they're arguing that having a separate storage device for
metadata will inflate the BOM cost unacceptably, and wouldn't it be
cheaper if we just redesigned XFS to have 2MB blocksize, but I'm not
buying that because the next thing they'll want when pmem becomes cheap
is 1GB blocksize for Big Data applications. :P)
--D
> Luis
next prev parent reply other threads:[~2020-02-19 17:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-19 13:57 Modern uses of CONFIG_XFS_RT Luis Chamberlain
2020-02-19 14:32 ` Carlos Maiolino
2020-02-19 14:38 ` Luis Chamberlain
2020-02-19 17:09 ` Darrick J. Wong [this message]
2020-02-19 17:55 ` Luis Chamberlain
2020-02-19 22:01 ` Darrick J. Wong
2020-02-20 0:17 ` Luis Chamberlain
2020-02-20 2:03 ` Darrick J. Wong
2020-02-20 2:12 ` Eric Sandeen
2020-02-20 2:15 ` Darrick J. Wong
2020-02-20 3:41 ` Dave Chinner
2020-02-20 14:25 ` Brian Foster
2020-02-20 22:06 ` Dave Chinner
2020-02-21 12:15 ` Brian Foster
2020-02-21 12:52 ` Emmanuel Florac
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=20200219170945.GN9506@magnolia \
--to=darrick.wong@oracle.com \
--cc=ailiopoulos@suse.de \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@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 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 NNTP newsgroup(s).