On Mar 2, 2014, at 12:43 PM, drago01 <drago01(a)gmail.com> wrote:
On Sun, Mar 2, 2014 at 8:25 PM, Adam Williamson
> 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
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.
We are being a bit loose with terminology considering LVM a file system. However, we had a
lot of problems with LVM Thin Provisioning compared to regular LVM during Fedora 20
pre-release testing. It wasn't working at all prior to or after Alpha, up until the
11th hour before beta release. And then it blew up in our faces again after it passed all
final release TC tests, it failed RC but it wasn't caught in time.
We also have a long standing grubby bug because it doesn't understand subvolumes.
Because of some change in anaconda, grub2-mkconfig sometimes happens before the initramfs
completes, so the grub.cfg doesn't have an initramfs entry. This gets fixed by grubby,
except when /boot is on Btrfs, resulting in a kernel panic on boot. So now we disallow in
Fedora 20 /boot on Btrfs subvolumes even in Manual Partitioning where it was previously
XFS doesn't support shrink. Do we have a bug somewhere in the installer that makes
the user think it is? Does the installer try to shrink it? Or a bug when trying to grow
it? Doubtful. But possible.
Arguably, we ought to be considering dumping ext2 and ext3 as fs options. The ext devs
will freely admit that ext2 and ext3 aren't getting backports from the rather active
ext4 work that's on-going, with any sort of consistency. So why should we be