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@xxxxxxxxxxxxx