On 4/29/18 6:23 AM, Peter Robinson wrote: >>>> On 28/04/18 14:55, Peter Robinson wrote: >>>>> On Sat, Apr 28, 2018 at 11:09 AM, Daniel Walsh <dwalsh@xxxxxxxxxx> >>>>> wrote: >>>>>> We are adding some features to container projects for User Namespace >>>>>> support >>>>>> that can take advantage of XFS Reflink. I have talked to some of the >>>>>> XFS >>>>>> Reflink kernel engineers in Red Hat and they have informed me that >>>>>> they >>>>>> believe it is ready to be turned on by default. >>>>>> >>>>>> I am not sure who in Red Hat I should talk to about this? Whether we >>>>>> should >>>>>> turn it on in the installer or in the mkfs.xfs command? >>>>>> >>>>>> Who should I be talking to? To make this happen. >>>>> I would speak to Eric Sandeen I believe he's the Red Hat maintainer >>>>> (or one of them) of XFS. >>>>> >>>>> Peter >>>> Indeed, and also we should look at this in the context of what is done >>>> for upstream. Ideally Fedora would just inherit the changes there, and there >>>> should not be anything special required for Fedora, >>>> >>>> Steve. >>> >>> So, for context, I am the upstream maintainer of xfsprogs as well as for >>> Fedora xfsprogs. >>> >>> Historically, new features in XFS have gone from "Experimental" (i.e. >>> under >>> development), then dropped Experimental (development is ~done) but still >>> optional, >>> and eventually default. We do this very conservatively, to give bugs a >>> chance >>> to shake out, which is one of the reasons XFS has a good reputation for >>> /not/ >>> eating your data. >>> >>> Reflink on XFS only recently dropped "Experimental" and is not yet default >>> upstream; >>> it won't be default upstream for some time to come - think on the order of >>> months. >>> >>> However, we do want to give reflink more exposure, and so jumping the gun >>> a bit and >>> turning it on for rawhide / Fedora 29 is probably a good idea. >>> >>> I'm mostly ok with patching it on by default in mkfs.xfs; it does confuse >>> things a bit >>> when "our" version behaves fundamentally differently from upstream, but >>> it's probably >>> the right thing to do here. I'll make sure that none of the other xfs >>> developers have >>> strong objections, and if not, I'll patch it in for fedora 29. >>> >>> Unless this should be a full blown Feature? If so, I'm ok with following >>> that path >>> as well. >> >> >> >> XFS is the default filesystem on Fedora Server Edition, so yes: I think we >> should really have a System-Wide Change Proposal submitted for this, >> primarily to ensure that the information is spread widely (Change Proposals >> like this are picked up by Fedora Marketing and tech news, so it’ll be more >> widely dispersed than just on the fedora-devel list). > > Assuming that the plan is to leave it enabled in F-29 on branching and > have it ship enabled in F-29 I agree, if the intention is to leave it > enabled in rawhide and disable it on branching then the Change > Proposal mechanism isn't the way to ensure wider knowledge. I'd be happy to have it left on for F29, it /might/ even be default upstream by the time F29 ships. I'll need to re-familiarize myself w/ the "System-Wide Change Proposal" process, I guess. FWIW, turning it on has very little effect until it's actually used, so it really should not be destabilizing for most, even if bugs lurk. ;) -Eric _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
