Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Roberto Ragusa]

On 05/02/2018 11:35 AM, Marius Vollmer wrote:
> Neal Gompa  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 consider that an annoying limitation of ext4, and I would not expect
a replacement filesystem to remove features instead of adding them.

We should have got online shrinking as standard nowadays, IMHO.

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HO4PILV5VQQRPBTSIDR52CF25HW5P3K3/

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Chris Murphy]

Late and off-topic by now, but in retrospect my response is closer to
stupid than the intended hyperbolic+funny.

On Wed, May 2, 2018 at 3:21 PM, Chris Murphy  wrote:
> On Wed, May 2, 2018 at 7:07 AM, Martin Kolman  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?"

Criticism of negative user experience is not at all inhibited by the
code of conduct. And couching such criticism in hyperbole confuses the
argument I was trying to make, while also unintentionally suggests a
recommendation intended to result in better experience comes from
substance abuse. That's just gross and disappointing. And I apologize
for it.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/I73XHY7WUHTOVLM5NQUWZGKGT4IQLQ2S/

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Eric Sandeen]

On 4/29/18 11:45 AM, Eric Sandeen wrote:
>> 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

Getting back on topic (back from the Shrink Wars), I'd like to get this
turned on.  I'd prefer to do this via a soon-to-land patch which enables
config files for mkfs, so that distros can set their own defaults without
having to patch source.  I'm going to give it a bit of time to see if we
can get that upstream, and then will see about simply shipping that
patch along w/ a config file that enables reflink for F29.

Thanks,
-Eric
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Stephen John Smoogen]

On 2 May 2018 at 18:49, Chris Murphy  wrote:
> On Wed, May 2, 2018 at 7:25 AM, Eric Sandeen  wrote:
>> On 5/2/18 7:15 AM, Neal Gompa wrote:
>>> On Wed, May 2, 2018 at 5:36 AM Marius Vollmer 
>>> wrote:
>>>
 Neal Gompa  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.

My understanding was that NTFS shrink was to get a sales check mark
versus a supported feature. You could shrink a FAT file system so
customers wanted NTFS to be shrinkable too so enough was implemented
to make it happen but it was not recommended to be done unless last
resort. [The other story was that Unix file systems could not shrink
and it would be a 'this is better than Unix' checkmark to show off in
a sales demo. ] In practice, shrinking NT 3.51/4.0 was a nightmare
with blowups happening for many odd reasons. I got tired of walking
customers through recovery steps and blaming Linux on destroying their
Windows system by the time I left Red Hat support in 2000.

When I did help desk at a large facility, Windows 2000 was better but
would blowup occasionally . We found that Windows XP was pretty
reliable to shrink with no blowups during shrinkage. Instead what
happened was many unexplained problems afterwords. Higher number of
BSoD, drivers being there on disk but the OS saying 'nope' sometimes,
file metadata gone versus corrupt. [My windows admins friends said 7
was better than XP, and that they have had much better luck with 10,
but that people aren't dual booting or shrinking file systems as much
as they used to.]

The server admins never reported crashes during shrinking but the
help-desk admins I worked with, it was a different story. I expect it
has to do with the fact that servers usually have more control of
'best practices' being done, while the desktop/laptop can have all
manner of things running which can affect file integrity in some way.
If it wasn't a server, the usual response from Microsoft was that if
it happened after a shrink, reinstall. If it happened again after that
open a ticket through the contract support.

For a lot of us, working out all the steps to shrink a disk properly
and deal with possible hangups is second nature. We can say 'of course
we should be able to shrink disks'. We also know when not to try and
shrink a disk unless we have done some steps before hand.  However, a
lot of the people who are going to try and shrink a disk are just
following whatever stackoverload voted the highest that day. It isn't
going to say 'well you know if you are at 90% on that version of
BTRFS/EXT/JFS you don't want to shrink it until you have updated XYZ.'
or some other thing you know to look out for. Instead as you say they
are going to expect that it will work all the time just like they
expect seat belts to keep them alive at 100 mph crash.

In any case, I think we have completely lost any link to the original topic.

-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Chris Murphy]

On Wed, May 2, 2018 at 7:25 AM, Eric Sandeen  wrote:
> On 5/2/18 7:15 AM, Neal Gompa wrote:
>> On Wed, May 2, 2018 at 5:36 AM Marius Vollmer 
>> wrote:
>>
>>> Neal Gompa  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.

I think there's a general expectation on Linux desktop systems to be
able to make room for some other OS.

> 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.

Btrfs excluded. It's either the same (the supers get new size
information and that's the only change), or block group migration
moves extents closer together and on a spinning disk toward the faster
sections. A shrink is essentially a partial balance, and so operation
ends up being more efficient.

> 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?

It's completely unnecessary on a file system designed for shrinking.

And sure, I get you're talking about file systems not really designed
for it. NTFS shink reliability probably has more to do with how
ancient it is, tons of users, and a lot of weird ancient junk it runs
on - they've had a lot of opportunities to catch the edge cases -
rather than design. But I haven't heard any Windows admin consider it
dangerous or invasive. I've never had NTFS shrink blow up.

I did once have JHFS+ on Core Storage LV blow up on me, although I was
being kind of a saboteur: shrink grow shrink grow shrink grow shrink
KABOOM.


> And if you have a backup, you're halfway to mkfs & restore, which will
> leave you in a much better place.
>
> So yes, you can shrink ext4, but it really should be seen as a last resort
> IMHO.  I know it can be expedient at times, but I'm not sure people really
> consider the downsides of the action.  On the surface, "yay it's smaller
> now!" but a bit more investigation shows that it's a de-optimizing,
> potentially dangerous administrative action.  Just my $0.02.

:-P

This thread reminds me of a Start Trek IV scene:

McCoy: My God, man! Drilling holes in his head isn't the answer! Now
put away your butcher knives and let me save this patient before it's
too late!


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Nico Kadel-Garcia]

On Wed, May 2, 2018 at 9:25 AM, Eric Sandeen  wrote:
> On 5/2/18 7:15 AM, Neal Gompa wrote:
>> On Wed, May 2, 2018 at 5:36 AM Marius Vollmer 
>> wrote:
>>
>>> Neal Gompa  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?

I've used it several times in the last year, usually to re-arrange
storage so that a cache is on a separate filesystem and less likely to
screw up the whole working environment.

> 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.

Locality is *much* less critical with modern flash drives.

> 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?

Yes, they would. So what? While it's common to stop a filesystem,
backup a directory, and re-assign a new partition mounted locally to
restore the data to, this can be a *very* painful operation.

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

In theory, yes, which is why I personally prefer to use such tools.
But doing this to "/" when someone has used default partitioning and
you need to clean it up later with minimal downtime is very expensive
in manpower.

> So yes, you can shrink ext4, but it really should be seen as a last resort
> IMHO.  I know it can be expedient at times, but I'm not sure people really
> consider the downsides of the action.  On the surface, "yay it's smaller
> now!" but a bit more investigation shows that it's a de-optimizing,
> potentially dangerous administrative action.  Just my $0.02.
>
> -Eric
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Chris Murphy]

On Wed, May 2, 2018 at 7:07 AM, Martin Kolman  wrote:
> On Mon, 2018-04-30 at 18:16 +, Neal Gompa wrote:
>> On Mon, Apr 30, 2018 at 2:14 PM Jason L Tibbitts III 
>> wrote:
>>
>> > > > > > > "CW" == Colin Walters  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.
> 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.

There's one option that meets the discussion requirements without the
fragile out of space, harder to fix, obscure errors and warnings, and
byzantine interface of LVM (thinp).

And that option has had stable reflink copies, snapshots, and online
resize (shrink and grow) for over 6 years; and is actually being used
by thousands of ordinary desktop Linux users; and without the
handholding that LVM requires or confusion it induces.

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?"

And I say this as a user of LVM thinp for VM's and my fifth backup
system (sorta funny, do I trust it? Or don't I? I trust it but hope to
god I don't have to? Yes.)

> Of course as with any thin-provisioning you are also giving up things,
> such as easily finding out how much free space is actually available to
> a given storage volume.

Giving up things like sanity and time as well. I'm not trying to be
mean, I'm completely serious. I've volunteered for the experience,
it's bad ass in many ways, but it is not something I'd foist on the
community by default. I'm vaguely open to the idea of Server using it,
but mostly skeptical.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Ian Pilcher]

On 05/02/2018 08:56 AM, Eric Sandeen wrote:

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


I'm sitting in a hotel room with a laptop.  What do I backup *to*?


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.


See above.


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.


Ack.

I personally think that it's fine that XFS can't shrink.  It's just
important to be clear about the use cases for which it's intended.  I
also get uncomfortable with just dismissing use cases like this without
considering that there may be legitimate reasons for them.

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Nicolas Mailhot]

Le 2018-05-02 15:25, Eric Sandeen a écrit :

On 5/2/18 7:15 AM, Neal Gompa wrote:


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?


Desktops because they have no planning (poor or otherwise) pretty much 
by definition.



--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Eric Sandeen]

On 5/2/18 8:42 AM, Ian Pilcher wrote:
> On 05/02/2018 08:25 AM, Eric Sandeen wrote:
>> 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?
> 
> The point isn't so much that you need it on a regular basis, it's that
> when you need it, you *really* need it.

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

I mostly want to point out that shrink permanently de-optimizes your
filesystem, and carries some risk as well, especially if you have no
backups.

> I'll buy the poor planning argument on a server that does pretty much
> the same thing for the entirety of its life/deployment, but the case of
> a laptop/desktop that goes years without being reinstalled, and then
> unexpectedly needs tens of gigabytes of space to bisect a kernel bug
> is very different.

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.

-Eric
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Ian Pilcher]

On 05/02/2018 08:25 AM, Eric Sandeen wrote:

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?


The point isn't so much that you need it on a regular basis, it's that
when you need it, you *really* need it.

I'll buy the poor planning argument on a server that does pretty much
the same thing for the entirety of its life/deployment, but the case of
a laptop/desktop that goes years without being reinstalled, and then
unexpectedly needs tens of gigabytes of space to bisect a kernel bug
is very different.

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Eric Sandeen]

On 5/2/18 7:15 AM, Neal Gompa wrote:
> On Wed, May 2, 2018 at 5:36 AM Marius Vollmer 
> wrote:
> 
>> Neal Gompa  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.

So yes, you can shrink ext4, but it really should be seen as a last resort
IMHO.  I know it can be expedient at times, but I'm not sure people really
consider the downsides of the action.  On the surface, "yay it's smaller
now!" but a bit more investigation shows that it's a de-optimizing,
potentially dangerous administrative action.  Just my $0.02.

-Eric
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Martin Kolman]

On Mon, 2018-04-30 at 18:16 +, Neal Gompa wrote:
> On Mon, Apr 30, 2018 at 2:14 PM Jason L Tibbitts III 
> wrote:
> 
> > > > > > > "CW" == Colin Walters  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.
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.

Of course as with any thin-provisioning you are also giving up things,
such as easily finding out how much free space is actually available to
a given storage volume.


> 
> 
> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Neal Gompa]

On Wed, May 2, 2018 at 5:36 AM Marius Vollmer 
wrote:

> Neal Gompa  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).


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Marius Vollmer]

Neal Gompa  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Eric Sandeen]

On 4/30/18 1:16 PM, Neal Gompa wrote:
> On Mon, Apr 30, 2018 at 2:14 PM Jason L Tibbitts III 
> wrote:
> 
>>> "CW" == Colin Walters  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

As we discussed on IRC, I think idle filesystems won't get these wakeups;
if this is still a concern, investigation of the actual effects on battery
life (if any) are recommended.

> 
> 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.

XFS realistically is not going to get shrink.  Fedora will need to decide if
the other capabilities & features outweigh the lack of shrink capability.

-Eric
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Dusty Mabe]

On 04/30/2018 02:16 PM, Neal Gompa wrote:

> 
> 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.

Yes! I've been wanting that for a long long time!

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Neal Gompa]

On Mon, Apr 30, 2018 at 2:14 PM Jason L Tibbitts III 
wrote:

> > "CW" == Colin Walters  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.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Jason L Tibbitts III]

> "CW" == Colin Walters  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

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Colin Walters]

On Sun, Apr 29, 2018, at 6:47 AM, Stephen Gallagher wrote:

> XFS is the default filesystem on Fedora Server Edition, 

And we use Server partitioning now for Atomic Host.  But for the
vast majority of times people say "Fedora" they're talking about
as a desktop.  And Workstation uses the Anaconda defaults which are
ext4 today.  See also
https://pagure.io/pungi-fedora/pull-request/257
I'd say it makes sense to revisit the default here globally in Anaconda.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Eric Sandeen]

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 
> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Peter Robinson]

>> > On 28/04/18 14:55, Peter Robinson wrote:
>> >> On Sat, Apr 28, 2018 at 11:09 AM, Daniel Walsh 
>> >> 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Stephen Gallagher]

On Sat, Apr 28, 2018 at 11:37 PM Eric Sandeen  wrote:

>
>
> 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 
> 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).



> thanks,
> -Eric
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Eric Sandeen]

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  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Steven Whitehouse]

Hi,


On 28/04/18 14:55, Peter Robinson wrote:

On Sat, Apr 28, 2018 at 11:09 AM, Daniel Walsh  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Peter Robinson]

On Sat, Apr 28, 2018 at 11:09 AM, Daniel Walsh  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Daniel Walsh]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org