On 3/3/14, 5:57 PM, Jon wrote: > On Sat, Mar 1, 2014 at 3:18 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> >> On Mar 1, 2014, at 1:19 PM, Jon <jdisnard@xxxxxxxxx> wrote: >> >>> The inability to shrink or reduce XFS is rather disappointing. I've >>> seen a few sarcastic remarks along the lines of (paraphrased): why >>> would anyone ever want to shrink a volume? >> >> In the context of server, and default installs, why is a valid question. >> >> >>> People do shrink volumes, and this lack of flexibility is an important >>> consideration I feel was ignored in the Server WG decision. >> >> What is the use case for volume shrinking in a server context? Dual boot is a total edge case for servers. > > In the context of Fedora-ARM, people would regularly shrink ext4 > filesystem images to fit on different size storage. > We would release an 8GiB image, but the ARM board might only have 4GiB > eMMC or somebody has a smaller sdcard (stuff like that). For what it's worth, this sort of shrinking & growing can lead to some pretty pessimal fs layouts. > We no longer release Fedora ARM rootfs tarballs, too hard to educate > people to do the right thing with ACL's, xattrs, selinux, etc... > Anyhow, it's actually a great way to ship a Fedora rootfs... just > shrink the filesystem down to the smallest size, and allow the user to > simply resize2fs the image into their storage. > This would not be possible with XFS for the server variant of > Fedora-ARM, and I feel represents a significant challenge to the ARM > team. I was never sure why shrinking was particularly required; maybe it's a little harder or slower, but: do an install, see how much space it used, make a new filesystem with 105% of that space (or so) and install onto that. Done and done? OTOH, the shrinkfs dance was a great way to find myriad bugs in resize2fs. ;) Making a tiny xfs FS and then growing it significantly will also lead to pessimal layouts there - we'll end up with many, many very small allocation groups. The shrink/grow thing was clever, but also a bit abusive from a filesystem design point of view. > > As for the real world examples of shrinking, well drawing upon my > experiences in the past at a managed hosting company: > > * VG consisted of ten 100 GiB san luns, customer asks one be removed, > and provisioned to another server. We shrunk the filesystem, and > removed the lun per request. > > Shrinking support significantly reduced the time needed for that > maintenance window! > Or put another way, shrinking is much faster than formatting and > restoring data from tape to achieve smaller sized volumes. > > > * customer over estimated the requirements for one mount (lets say > /opt for example), and underestimated the requirements of another (say > /var/log for example). > This classic example of where customers fail to properly anticipate > the storage requirements of their work-flow at the time of install, > and they shrink one to grow another. > (this might be solved by the thin provisioning idea) > > > * customer wanted to shrink the SAN luns to a smaller size, but was > averse to significant down time to restore from tape. > ext4 shrinking to the rescue! It's handy at times, but shrinking really scrambles data layouts. If you don't care about performance, it's probably ok. -Eric -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
