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