-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/01/2014 04:18 PM, Chris Murphy 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. > > I just want to reiterate that this is what we are recommending for a purely default installation. This is what you get only if you decide not to customize your partitioning in any way. I expect this to be the exception, not the rule, for Server deployments. However, we want to have something in place for the "Let's try this out and see what happens" crowd of potential converts. In that case, I think having a set of defaults focused on performance and scalability will go a longer way down the path of bringing people around than filesystem shrinking. That's not to say that there's anything inherently wrong with EXT4. We just feel that XFS is better suited to our default offering. >> 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 I asked Ric Wheeler (the lead for Red Hat's storage and filesystem) to provide some justifications. He responded elsewhere in this thread, which I'll repeat here in case it was missed: "XFS has many advantages: * best performance for most workloads (especially with high speed storage and larger number of cores) * tends to be less CPU intensive (better optimizations around lock contention, etc) * most robust at large scale - has been run at hundred plus TB sizes for many years (and today's storage is getting way bigger, 16TB is about half a shelf of drives) * XFS is the most common file system in multiple key upstream communities: most common base for ceph, gluster and openstack more broadly * pioneered most of the techniques now in ext4 for performance (like delayed allocation) That said, ext4 has not been standing still: * it has made major advances as well in the past few years in closing in on XFS features * goes toe to toe with XFS in many workloads, especially on smaller storage sizes. It will tend to be faster than XFS with some specific workloads (like single threaded, metadata intensive workloads) * commonly used file system in major sites & systems (google, android, RHEL6) I think that having XFS as the default for servers and ext4 as a default for workstations is reasonable. As part of the group that works on both, it won't make our lives any crazier Ric " > 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. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMUdLUACgkQeiVVYja6o6MywQCeP9QpKtKw4fRhiFtSZuC5OnHC sLQAn0Fgx2tZZ/KOAR7t1s67Nu6jDBrt =MtyA -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
