On 12/1/15 2:26 PM, Dave Chinner wrote: > On Tue, Dec 01, 2015 at 09:30:00AM +0100, Martin Steigerwald wrote: >> Am Dienstag, 1. Dezember 2015, 08:41:04 CET schrieb Dave Chinner: >>> On Thu, Nov 26, 2015 at 11:21:45AM +0100, aluno3@xxxxxxxxxxxxxx wrote: >>>> Hello, >>>> >>>> I am using kernel 3.10 and would like to update xfsprogs (currently I >>>> have 3.1.5). >>>> >>>> When I tried to use the newest version of xfsprogs 4.3.0 I get the call >>>> trace about detected version 5 of superblock when mounting volume which >>>> was formatted using mkfs.xfs from 4.3.0. >>> >>> More recent xfsprogs versions enable features that are only >>> supported by recent kernels. We tend to wait at least a year before >>> enabling new features by default in xfsprogs so that kernel support >>> is usually picke dup by distros before they update xfsprogs.... >>> >>> If you have an old kernel, then you need to turn off the newer >>> features that your kernel does not support. This has always been the >>> case - if you update the xfsprogs yourself, then you need to use the >>> correct options for your kernel. In general, this: >>> >>> # mkfs.xfs -f -m crc=0 -n ftype=0 <dev> >>> >>> will make a filesystem that can be mounted on old kernels. If >>> distros are shipping old kernels with new xfsprogs and are not >>> changing the default behaviour to suit their kernel, then that is a >>> distro problem. >> >> How about just checking running kernel version before enabling this by >> default? > > The btrfs solution? No thanks. Another option is to export features the running kernel can handle in sysfs & mkfs accordingly - but then somebody mkfs's under one kernel, boots another kernel, and gets different mkfs's, possibly fails to mount, etc... magically changing defaults is a nightmare. yeah, at some point you have to realize that you cannot save everyone from themselves. ;) > Apart from the fact I make filesystems that the kernel does not > support all the time, xfstests does the same thing so that we can > test that the kernel correctly rejects mounts of filesystems with > features it doesn't support. And this fails when a distro installer > or rescue distro has a different kernel to the one the distro > actually uses, too... > > And, really, where does this slipperly slope end? Suddenly we have > to maintain a map of every feature in every mainline kernel, then > every distro kernel that does backports (e.g. sles, rhel, etc) and > we end up with something nobody can maintain or test. > >> While this is some implementation effort, it may help to reduce questions on >> this mailing list. And as you see distro problem or not: People still ask >> here. :) Like Dave said - not very often at all. -Eric > The majority of distro's get it right the majority of the time - > there's no point in turning everything upside down just to silence a > very small vocal minority. i.e. It's only when users do their own > package upgrades, or a distro screws up (like gentoo with shipping > 3.2.4 on an old kernel) that users end up with a problem. > > Cheers, > > Dave. > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
