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.
for me
personally, I'm not sure any performance gains are enough to
compensate for the lack of flexibility. Considering that LVM has the
ability to resize volumes, ext4 pairs very well,
Unless you use system-storage-manager, you might refresh the steps required to do an ext4
on LVM resize. I don't think the person who understands how to do that is really the
target audience for default installs.
and I'm skeptical
thin provisioning does enough make-up for the lack of XFS shrinking.
It even makes up for ext4 shrinking in two ways. 1. Instead of making an LV smaller than
possibly needed, make it the size it probably should be from the start. It only consumes
extents from the thinpool as needed. 2. Upon significant file deletion, fstrim returns
unused extents back to the thinpool.
This is faster, more efficient, and less fragile than file system shrink. Again, the
problem is that commands are a bit esoteric, but maybe system-storage-manager can help out
with this once it support thin provisioning.
So my question to the Server WG, did anybody consider this aspect of
XFS (lack of shrinking) before making the decision? What were the
highest reasons for NOT staying with EXT4?
I realize the thread has well over 100 emails in it, but it was considered. The simple
explanation why XFS was chosen is because it was well vetted by Red Hat storage experts
for use as the default in RHEL 7 - and I understand that sgallagh is working on a summary
of those reasons, which would apply here as well. I'd say top on the list is XFS is
scales linearly as more threads are thrown at it, it's very good at parallelism, and
it support project quotas which often obviates the need to create separate file systems as
a means of constraining storage usage rather than doing it only by user or group.
Chris Murphy