On 2/20/18 3:02 PM, Dave Chinner wrote: > On Tue, Feb 20, 2018 at 08:33:47AM -0800, Darrick J. Wong wrote: >> On Tue, Feb 20, 2018 at 09:09:22AM -0600, Eric Sandeen wrote: >>> (resend, somehow I keep missing reply-all) >>> >>> That would be much faster than at least our historical progression >>> for new features: >>> >>> * Experimental for $LONG_TIME >>> * Drop experimental for $SIGNIFICANT_TIME >>> * Make default after that >> >> ISTR Dave once telling me that he usually waited ~4 kernel releases to >> drop the experimental tag and then another year to turn it on by >> default in mkfs. I'll grant you that seven kernels went by before >> EXPERIMENTAL went away, so I don't think we need to wait a whole other >> year. How about turning it on by default in July or so? > > The wait time for "supported -> default" is so that distro's have > time to move to a feature supported kernel before they pick up a new > xfsprogs release that turns on that feature by default. this mostly > avoids the problem of distros accidentally turning on a feature that > is still experimental in their kernel.... Speaking for Fedora, it brings userspace & kernelspace into a distro together, so that's not a problem. Speaking for RHEL, it's a long term distro that knows darned well that mixing and matching new & old requires care, if it's done at all. > It also gives us "early adopter" feedback before large numbers of > unsuspecting users have it enabled for them.... *nod* >> Speaking of which, hasn't enough time passed to enable spinodes by >> default in mkfs? Given the likelihood of worse fragmentation once we >> add cow into the mix, we probably want that turned on before reflink. >> >> Hm.... EXPERIMENTAL was removed for spinodes in July 2016, so that >> probably could be turned on "now". > > Yup, enough time has passed there. Uh, ok, 4.16 then? Maybe not something to do at the very last minute of 4.15. >>> My sense is that it's a bit premature, having /just/ dropped the >>> EXPERIMENTAL tag, which will (in theory) get more people using >>> it in earnest and maybe shaking out more bugs. >>> >>> But I'd like to hear what others think as well. >> >> There's already too much new stuff in mkfs 4.15; let's wait for .17 >> because that'll give the more cautious testers more time to find >> whatever other bugs still lurk. :) > > I think even that is too fast. If distro's want it as the default > before we set it, then they can patch mkfs themselves. Again speaking with my own distro maintainer hat on, I hate backporting fundamental changes in behavior like that. It's easier on everyone if xfsprogs version $FOO has a well known, consistent set of features, but - > If this is really a huge problem for distros, then wasn't this what > someone wanted mkfs config files for? Suse folk seem to like that approach, yes. But while the config file facilitates that sort of distro approach, it isn't really a hard requirement, I'd think - patching is always an option in the end. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
