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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2 May 2018 at 18:49, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
> On Wed, May 2, 2018 at 7:25 AM, Eric Sandeen <sandeen@xxxxxxxxxx> wrote:
>> On 5/2/18 7:15 AM, Neal Gompa wrote:
>>> On Wed, May 2, 2018 at 5:36 AM Marius Vollmer <marius.vollmer@xxxxxxxxxx>
>>> wrote:
>>>
>>>> Neal Gompa <ngompa13@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux