On Mar 4, 2014, at 11:28 AM, Dennis Gilmore <dennis(a)gilmore.net.au> wrote:
Im working towards making anaconda installs the preferred install
method, which on some hardware today it already is.
OK good to know. This reinforces my thinking. Is it sane for ARMv7 to have its own fs
default? Or should all of the archs for a product compromise?
Each deliverable must have its default partitioning tested. If there are 3x deliverables,
that's 3x default partition testing. I don't see that it matters if each
deliverable had a different default fs/layout, because that's still just one default
for that one deliverable. It's not multiplicative. Whereas before with four Partition
Scheme options, 3x deliverables means 12x paths. It's a lot more testing to have
options. One default fs/layout is a passthrough for each of the deliverables regardless of
what it is, testing wise, but maybe this is untenable for anaconda or for composes?
we make images via
appliance-creator which today doesn't support XFS at all, though that's
easily fixed.
OK. Does the anaconda default bind you into making this change in appliance-creator? Or is
it a preference? And if it's a preference is it really making things easier to be all
on the same thing, even though all offerings would have to be tested in any case?
We have a 22T XFS filesystem in Fedora infrastructure today. because it
was the only way to get one that big.
That 22TB file system isn't running on a 32-bit kernel though.
I'm fine with XFS on x86_64, as it's very well tested there. And i686 doesn't
bother me much as it sounds like it gets good upstream testing. I'm a little more
concerned about it on 32-bit ARM though just because of the unknowns.
Chris Murphy