default file system, was: Comparison to Workstation Technical Specification

Chris Murphy lists at colorremedies.com
Sat Mar 1 23:57:06 UTC 2014


On Mar 1, 2014, at 2:40 PM, Nathanael Noblet <nathanael at gnat.ca> wrote:

> On 03/01/2014 02:18 PM, Chris Murphy 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.
> Recently I had a client who required that some data be on an encrypted partition. The servers were rented from a datacenter instead of being cloud based etc. As such you don't have access to the kickstart used to initialize and install the OS. So we had to shrink the rootfs to make room for a new lvm partition for the data. I've had to do that a handful of times for various reasons but the above is the most recent.

The servers were rented with a Fedora produced default/automatic/guided partitioning layout? If not, your example is out of scope. We are only talking about this context specifically, not arbitrary examples for shrinking a file system.

The Fedora automatic/guided partition layout is a rootfs of 50GB, and any significant additional space goes to a separate /home. So you're saying you'd shrink a 50GB rootfs for encrypted data, rather than blow away the /home LV, make a new LV, encrypt it, then format it?



Chris Murphy




More information about the devel mailing list