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. 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
