On Mar 4, 2014, at 11:28 AM, Dennis Gilmore <den...@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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
