On Thu, Feb 20, 2020 at 12:17:29AM +0000, Luis Chamberlain wrote: > On Wed, Feb 19, 2020 at 02:01:04PM -0800, Darrick J. Wong wrote: > > On Wed, Feb 19, 2020 at 05:55:02PM +0000, Luis Chamberlain wrote: > > > On Wed, Feb 19, 2020 at 09:09:45AM -0800, Darrick J. Wong wrote: > > > > 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. > > > > > > Is anyone productizing on that though? > > > > > > I was curious since most distros are disabling CONFIG_XFS_RT so I was > > > curious who was actually testing this stuff or caring about it. > > > > Most != All. We enabled it here, for development of future products. > > Ah great to know, thanks! > > > > > 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. > > > > > > For those that *are* using XFS in production with realtime volume with dax... > > > I wonder whatcha doing about all these tests on fstests which we don't > > > have a proper way to know if the test succeeded / failed [0] when an > > > external logdev is used, this then applies to regular external log dev > > > users as well [1]. > > > > Huh? How did we jump from realtime devices to external log files? > > They share the same problem with fstests when using an alternative log > device, which I pointed out on [0] and [1]. > > [0] https://github.com/mcgrof/oscheck/blob/master/expunges/linux-next-xfs/xfs/unassigned/xfs_realtimedev.txt > [1] https://github.com/mcgrof/oscheck/blob/master/expunges/linux-next-xfs/xfs/unassigned/xfs_logdev.txt > > > > Which makes me also wonder then, what are the typical big users of the > > > regular external log device? > > > > > > Reviewing a way to address this on fstests has been on my TODO for > > > a while, but it begs the question of how much do we really care first. > > > And that's what I was really trying to figure out. > > > > > > Can / should we phase out external logdev / realtime dev? Who really is > > > caring about this code these days? > > > > Not many, I guess. :/ > > > > There seem to be a lot more tests these days that use dmflakey on the > > data device to simulate a temporary disk failure... but those aren't > > going to work for external log devices because they seem to assume that > > what we call the data device is also the log device. > > That goes to show that the fstests assumption on a shared data/log device was > not only a thing of the past, its still present, and unless we address > soon, the gap will only get bigger. > > OK thanks for the feedback. The situation in terms of testing rtdev or > external logs seems actually worse than I expected given the outlook for > the future and no one seeming to really care too much right now. If the > dax folks didn't care, then the code will likely just bit rot even more. > Is it too nutty for us to consider removing it as a future goal? Yes. You just jumped from "I haven't had time to triage these failing tests" straight to ripping out code. Analyze the failures, fix the tests that weren't designed flexibly enough to handle, and we'll discuss the ones that aren't easily changed. --D > Luis
