default file system, was: Comparison to Workstation Technical Specification

[Jon]

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

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.


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!





In the context of HP-UX I've been in the situation to perform online
shrinking with database running on the storage mount.
The point is that shrinking is an important feature in a server OS!!


>> 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.
>

I would disagree on the basis that people who do default install
probably are the same group of folks who might not plan ahead for
their future storage needs, which usually involves growing storage
(something XFS is great at doing), and other times involves shrinking.
However these are my 2-bit opinions, all I'm say is we advocate for
those consumers who make mistakes, and that we please consider &
recongnize that XFS has less tolerance for when the mistake happens to
be provisioning too much storage.

>
>> 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.
>
Thin provisioning sounds great, but I'm not sure it replaces the
ability to shrink in all situations, but it appears to negate many of
the situations I've mentioned, but not all.

>> 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.
>
>

I would imagine people turning their ARM dev board into a home NAS or
some similar storage kit, and the linear scale-up of XFS is really
appealing.



-Jon Disnard