Re: Which xfsprogs version to which kernel version

[Eric Sandeen <sandeen@sandeen.net>]

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@poczta.onet.pl 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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs