On 2 March 2014 14:56, Ric Wheeler <rwheeler@xxxxxxxxxx> wrote: > On 03/02/2014 01:17 PM, Ian Malone wrote: >>> >>> Can we get some definition of "legacy" here? kernel/nfs-utils versions? >>> > >> >> I'd have to check what I can share. If it helps: not current RHEL or >> recent Fedora, until recently some that were over five years old. Also >> this comment in the XFS FAQ: "Beware that some old programs might have >> problems reading 64bit inodes" which seems to be related to stat vs >> stat64, there are some old programs that might require us to modify. > > > Just to be clear, defaults are only important when you install. I don't > think anyone is suggesting compiling out the ext4 code from the kernel so > this should be of zero impact to someone running a file year old system who > wants to upgrade to something modern. > > If you need to stay on that five year old system and not upgrade, I am not > sure I understand why it would be a reasonable example. > > As other people have mentioned, there are ways to create an XFS instance > that does not use 64 bit inodes (but that is *not* a sane default since the > problems you refer to are not common with modern apps). > Yes, I maybe wasn't clear in my first email and the context has been a bit lost in people following up details. My point was really that there may be reasons for selecting a particular fs in a server context[1] and that people setting up servers will often want to change from the defaults. What seemed to be happening looked the wrong way around: talk about the workstation defaults being the same as the server ones, for not much more reason than the server decision was taken first. It now looks like the consensus is it *could* be different. [1] Aside: it's an NFS server with some older clients, so upgrading the server while retaining the clients would be a perfectly feasible scenario, and actually ext4 seems to be working as well for us as XFS did. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
