On 3/3/14, 5:57 PM, Jon wrote:
On Sat, Mar 1, 2014 at 3:18 PM, Chris Murphy
<lists(a)colorremedies.com> wrote:
>
> On Mar 1, 2014, at 1:19 PM, Jon <jdisnard(a)gmail.com> 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