On Mar 1, 2014, at 1:12 AM, Adam Williamson <awilliam(a)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. 
LVMthinp is a technically better workaround, even better than ext4 shrink, but it's
esoteric. It requires the same capability as  but in addition the 2nd installer needs
to: a. understand LVMthinp, b. permit thinpool overcomit which even anaconda presently
Therefore if plaint ext4 isn't on the table for Workstation, we're back to
Workstation (ideally) mimicking what Server does.
 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.
 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.