On Wed, May 2, 2018 at 7:25 AM, Eric Sandeen sandeen@redhat.com wrote:
On 5/2/18 7:15 AM, Neal Gompa wrote:
On Wed, May 2, 2018 at 5:36 AM Marius Vollmer marius.vollmer@redhat.com wrote:
Neal Gompa ngompa13@gmail.com 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!