Re: Modern uses of CONFIG_XFS_RT

[Brian Foster <bfoster@redhat.com>]

On Fri, Feb 21, 2020 at 09:06:52AM +1100, Dave Chinner wrote:
> 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).
> 

Ok, then we should be able to get those changes upstream.

> > 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....
> 

Well that's not what I said. ;P I'm pointing out that as of right now
this is a downstream only use case. I know there was upstream
communication and patches posted, etc., but that was a while ago and it
wasn't clear to me if there was still intent to get things merged
upstream. If not, then the only real outcome here for anybody outside of
FB is bitrot.

> > 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...
> 

I'm not sure if I'm digging out the right mails... it appears there was
decent upstream activity at first (up to a v7 [1] across a period of
months). Since then, I don't see any updates in over two years..

Brian

[1] https://lore.kernel.org/linux-xfs/20171128215527.2510350-1-rwareing@fb.com/

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
>