default file system, was: Comparison to Workstation Technical Specification

Chris Murphy lists at colorremedies.com
Sat Mar 1 19:03:03 UTC 2014


On Mar 1, 2014, at 1:12 AM, Adam Williamson <awilliam at redhat.com> wrote:

> On Fri, 2014-02-28 at 20:11 -0700, Chris Murphy wrote:
> 
>> There are advantages for server using XFS, even for the smaller
>> percent (?) who may end up using the default installation path.
>> There's no negative I think of for Workstation using XFS. So I'd say
>> make them both XFS.
> 
> The xfs negative I can see is the resizing thing. That's about it,
> really. (For anyone who's not aware: you can't shrink xfs partitions,
> currently. That means that people won't be able to shrink their Fedora
> install to install something else alongside it later).

I see the "install something else alongside Fedora" made most straightforward with plain ext4. [1]

LVMthinp is a technically better workaround, even better than ext4 shrink, but it's esoteric. It requires the same capability as [1] but in addition the 2nd installer needs to: a. understand LVMthinp, b. permit thinpool overcomit which even anaconda presently doesn't. [2]

Therefore if plaint ext4 isn't on the table for Workstation, we're back to Workstation (ideally) mimicking what Server does.


Chris Murphy


[1] Even with ext4+LVM it would mean either a.) two something's sharing one /boot, i.e. doable but not best practices; or .b) the followup installer has do LVM gymnastics galore to extract space for a new plain partition. I don't even know if anaconda custom partitioning does that.

[2] Anaconda is probably being overly conservative, by disallowing any amount of overcommitting, which is the whole idea behind thin provisioning: setting the maximum practical size for each file system's LV, and do a one time format, and the LV only takes from the thinpool what it actually uses. It obviates both grow and shrink resizing.


More information about the desktop mailing list