On Sat, Apr 28, 2018 at 11:09 AM, Daniel Walsh <dwalsh(a)redhat.com&gt; 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

On 4/28/18 9:21 AM, Steven Whitehouse wrote: > Hi, > > > On 28/04/18 14:55, Peter Robinson wrote: >> On Sat, Apr 28, 2018 at 11:09 AM, Daniel Walsh <dwalsh(a)redhat.com&gt; 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.

thanks, -Eric _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

>>> On 28/04/18 14:55, Peter Robinson wrote: >>>> On Sat, Apr 28, 2018 at 11:09 AM, Daniel Walsh <dwalsh(a)redhat.com&gt; >>>> 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.

XFS is the default filesystem on Fedora Server Edition,

>>>>> "CW" == Colin Walters <walters(a)verbum.org&gt; writes:

CW> I'd say it makes sense to revisit the default here globally in CW> Anaconda.

Maybe. Have the issues which made XFS less suitable for use on laptops been resolved? The primary one I recall was that each mounted filesystem would have a corresponding kernel thread doing about 20 wakeups per second. This was not really good for battery life and power consumption in general.

Last I checked (which was 2016 or so) those wakeups were slated to be around for a while longer. https://www.spinics.net/lists/xfs/msg40210.html

On Mon, Apr 30, 2018 at 2:14 PM Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; wrote: >>>>>> "CW" == Colin Walters <walters(a)verbum.org&gt; writes: > CW> I'd say it makes sense to revisit the default here globally in > CW> Anaconda. > Maybe. Have the issues which made XFS less suitable for use on laptops > been resolved? The primary one I recall was that each mounted > filesystem would have a corresponding kernel thread doing about 20 > wakeups per second. This was not really good for battery life and power > consumption in general. > Last I checked (which was 2016 or so) those wakeups were slated to be > around for a while longer. > https://www.spinics.net/lists/xfs/msg40210.html

And there's still the fun restriction of XFS not being able to shrink. It's not particularly important in the server case, but in the desktop/laptop case, it happens enough in my experience that I'm not sure I'd want a default filesystem that can't shrink.

Neal Gompa <ngompa13(a)gmail.com&gt; writes:

> And there's still the fun restriction of XFS not being able to shrink.

But note that even ext4 can't shrink while being mounted.

I've always seen the need for shrink as an indicator that someone had poor planning along the way, or insufficient tools for provisioning to start with. Sure, there are exceptions, but in general who needs shrink on a regular basis?

Given that it is exception activity, dump/mks/restore is also a less convenient but more robust solution to the problem.

If you're putting your years-old root or home filesystem at risk to bisect a bug I'd humbly suggest that an external or additional disk might be more suited to the task.

I don't have any real horse in this race - if Fedora feels that shrink capability trumps features like reflink, that's fine. Just offering my thoughts on the matter, and trying to point out that shrink has its downsides.

On 5/2/18 7:15 AM, Neal Gompa wrote: > On Wed, May 2, 2018 at 5:36 AM Marius Vollmer <marius.vollmer(a)redhat.com&gt; > wrote: > >> Neal Gompa <ngompa13(a)gmail.com&gt; writes: > >>> And there's still the fun restriction of XFS not being able to shrink. > >> But note that even ext4 can't shrink while being mounted. > > But it can shrink when it's not. This is incredibly important for being > able to deal with resizing both / and /home at the same time, or even > trying to make space for multi-booting (typically with Windows but some > people do other OSes too). I've always seen the need for shrink as an indicator that someone had poor planning along the way, or insufficient tools for provisioning to start with. Sure, there are exceptions, but in general who needs shrink on a regular basis?

Shrink is actually pretty damaging to the filesystem; it takes all the locality that the allocator tried to provide, and scatters it to the wind. The result is a stitched-together mess.

Not only that, but wouldn't any sane administrator with important data to take care of make a backup before an invasive action like shrink?

And if you have a backup, you're halfway to mkfs & restore, which will leave you in a much better place.

On Wed, May 2, 2018 at 7:25 AM, Eric Sandeen <sandeen(a)redhat.com&gt; wrote: > On 5/2/18 7:15 AM, Neal Gompa wrote: >> On Wed, May 2, 2018 at 5:36 AM Marius Vollmer <marius.vollmer(a)redhat.com&gt; >> wrote: >> >>> Neal Gompa <ngompa13(a)gmail.com&gt; writes: >> >>>> And there's still the fun restriction of XFS not being able to shrink. >> >>> But note that even ext4 can't shrink while being mounted. >> >> But it can shrink when it's not. This is incredibly important for being >> able to deal with resizing both / and /home at the same time, or even >> trying to make space for multi-booting (typically with Windows but some >> people do other OSes too). > > I've always seen the need for shrink as an indicator that someone had > poor planning along the way, or insufficient tools for provisioning to > start with. Sure, there are exceptions, but in general who needs shrink > on a regular basis? Even ancient NTFS does online shrink. It's not because it's regularly needed on a per user basis, it's because when needed it'd be a huge PITA to not have it. I don't know the origin story why NTFS got shrink capability. HFS and HFS+ did not originally have it, it happened with a bunch of other upgrades including journaling, soon thereafter was the switch to Intel CPUs, and "boot camp" support for dual boot. I'm pretty sure shrink support anticipated dual booting.

On Mon, Apr 30, 2018 at 2:14 PM Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; wrote: > > > > > > "CW" == Colin Walters <walters(a)verbum.org&gt; writes: > CW> I'd say it makes sense to revisit the default here globally in > CW> Anaconda. > Maybe. Have the issues which made XFS less suitable for use on laptops > been resolved? The primary one I recall was that each mounted > filesystem would have a corresponding kernel thread doing about 20 > wakeups per second. This was not really good for battery life and power > consumption in general. > Last I checked (which was 2016 or so) those wakeups were slated to be > around for a while longer. > https://www.spinics.net/lists/xfs/msg40210.html And there's still the fun restriction of XFS not being able to shrink. It's not particularly important in the server case, but in the desktop/laptop case, it happens enough in my experience that I'm not sure I'd want a default filesystem that can't shrink.

On Wed, May 2, 2018 at 7:07 AM, Martin Kolman <mkolman(a)redhat.com&gt; wrote:

> What about putting it on top of a thin-LV then ? With over provisioning you > could even share space efficiently between root & home and would get other > features such as efficient CoW snapshots.

First order of business for making LVM thinp a default for Workstation: a one cycle release of the code of conduct for the Fedora Community as it pertains to the change, so they can feel free to ask things like "what kind of drugs were you guys on when making this decision?"