From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Richard Wareing <rwareing@fb.com>,
linux-xfs@vger.kernel.org,
Anthony Iliopoulos <ailiopoulos@suse.de>
Subject: Re: Modern uses of CONFIG_XFS_RT
Date: Fri, 21 Feb 2020 09:06:52 +1100 [thread overview]
Message-ID: <20200220220652.GP10776@dread.disaster.area> (raw)
In-Reply-To: <20200220142520.GF48977@bfoster>
On Thu, Feb 20, 2020 at 09:25:20AM -0500, Brian Foster wrote:
> On Thu, Feb 20, 2020 at 02:41:06PM +1100, Dave Chinner 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.
> >
> > Facebook use it in production systems to separate large file data
> > from metadata and small files. i.e. they use a small SSD based
> > partition for the filesytem metadata and a spinning disk for
> > the large scale data storage. Essentially simple teired storage.
> >
>
> Didn't this involve custom functionality? I thought they had posted
> something at one point that wasn't seen through to merge, but I could be
> misremembering (or maybe that was something else RT related). It doesn't
Yes, but that is largely irrelevant. It requires the RT device to
function, and the RT device functionality is entirely unchanged. All
that changed was the initial data allocation policy to select
whether the RT or data device would be used, and that really isn't
that controversial as we've always suggested this is a potential use
of the RT device (fast and slow storage in the one filesystem
namespace).
> matter that much as there are probably other users out there, but I'm
> not sure this serves as a great example use case if it did require
> downstream customizations
There are almost always downstream modifications in private cloud
storage kernels, even if it is just bug fixes. They aren't shipping
the code to anyone, so they don't have to publish those changes.
However, the presence of downstream changes doesn't mean the
upstreram functionality should be considered unused and can be
removed....
> that aren't going to be generalized/supported
> for the community.. Richard..?
IIRC, we were simply waiting on an updated patchset to address
review comments...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2020-02-20 22:06 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
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 [this message]
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=20200220220652.GP10776@dread.disaster.area \
--to=david@fromorbit.com \
--cc=ailiopoulos@suse.de \
--cc=bfoster@redhat.com \
--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 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.