default filesystem

[Chris Murphy]

On Mar 2, 2014, at 1:16 PM, drago01 <drago01 at gmail.com> wrote:

> On Sun, Mar 2, 2014 at 9:12 PM, Adam Williamson <awilliam at redhat.com> wrote:
>> On Sun, 2014-03-02 at 20:43 +0100, drago01 wrote:
>>> On Sun, Mar 2, 2014 at 8:25 PM, Adam Williamson <awilliam at redhat.com> wrote:
>>>> On Sat, 2014-03-01 at 09:48 +0100, drago01 wrote:
>>>> 
>>>>> As for the installation QA I don't think the
>>>>> file system itself is a major source
>>>>> of churn / bugs.
>>>> 
>>>> The people who do the installation QA are the ones who are telling you
>>>> differently...
>>> 
>>> Care to provide any details? I mean I different partitions setups /
>>> raid / lvm / iscsi / $somethingthatalomostnooneuses ok .. but the fs ?
>>> All that anaconda has to do is call mkfs.whatever and add the proper
>>> name to fstab ... unless the mkfs.whatever itself is broken there
>>> shouldn't be much difference.
>> 
>> Sure, so we immediately have twice as many mkfs'es that could be broken.
>> We also have to make sure the tools are available to the installer
>> environment and the initramfs; that was what went wrong with LVM thinp
>> in F21 - the tools were missing from the initramfs because dracut
>> over-optimized. There's always one more darn thing.
>> 
>> Yes, difference between container/non-container and complex filesystems
>> like btrfs is more significant, but any difference adds failure points.
> 
> OK ... (I said "not a major source of bugs" not "never has any issues").

I don't see the distinction. LVM thinp blows up, it's a major bug if the user can't boot because not booting after install is typically a blocker bug, which is a major sort of bug. Grubby can't update grub.cfg because Btrfs subvolumes confuse it? It's a major bug, we compelled a code change to disallow /boot on Btrfs subvolumes because the grubby failure is silent with Gnome initiated updates and means updated kernels aren't ever used for booting - so it's potentially a security risk.


Chris Murphy