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. > 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
