On 2 May 2018 at 18:49, Chris Murphy <li...@colorremedies.com> wrote: > On Wed, May 2, 2018 at 7:25 AM, Eric Sandeen <sand...@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.voll...@redhat.com> >>> wrote: >>> >>>> Neal Gompa <ngomp...@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.
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
