Re: [PATCH 0/7] Let user specify the kernel version for features

[Anand Jain <anand.jain@oracle.com>]

On 11/26/2015 10:02 AM, Qu Wenruo wrote:
>
>
> Anand Jain wrote on 2015/11/25 20:08 +0800:
>> Sometimes users may want to have a btrfs to be supported on multiple
>> kernel version. A simple example, USB drive can be used with multiple
>> system running different kernel versions. Or in a data center a SAN
>> LUN could be mounted on any system with different kernel version.
>>
>> Thanks for providing comments and feedback.
>> Further to it, here below is a set of patch which will introduce, to
>> specify a kernel version so that default features can be set based on
>> what features were supported at that kernel version.
>
> With the new -O comp= option, the concern on user who want to make a
> btrfs for newer kernel is hugely reduced.

NO!. actually new option -O comp= provides no concern for users who
want to create _a btrfs disk layout which is compatible with more
than one kernel_.  above there are two examples of it.

> But I still prefer such feature align to be done only when specified by
> user, instead of automatically. (yeah, already told for several times
> though)
> Warning should be enough for user, sometimes too automatic is not  good,

As said before.
We need latest btrfs-progs on older kernels, for obvious reasons of
btrfs-progs bug fixes. We don't have to back port fixes even on
btrfs-progs as we already do it in btrfs kernel. A btrfs-progs should
work on any kernel with the "default features as prescribed for that
kernel".

Let's say if we don't do this automatic then, latest btrfs-progs
with default mkfs.btfs && mount fails. But a user upgrading btrfs-progs
for fsck bug fixes, shouldn't find 'default mkfs.btfs && mount'
failing. Nor they have to use a "new" set of mkfs option to create all
default FS for a LTS kernel.

Default features based on btrfs-progs version instead of kernel
version- makes NO sense. And adding a warning for not using latest
features which is not in their running kernel is pointless. That's
_not_ a backward kernel compatible tool.

btrfs-progs should work "for the kernel". We should avoid adding too
much intelligence into btrfs-progs. I have fixed too many issues and
redesigned progs in this area. Too many bugs were mainly because of the
idea of copy and maintain same code on btrfs-progs and btrfs-kernel
approach for progs. (ref wiki and my email before). Thats a wrong
approach. I don't understand- if the purpose of both of these isn't
same what is the point in maintaining same code? It won't save in
efforts mainly because its like developing a distributed FS where
two parties has to be communicated to be in sync. Which is like using
the canon to shoo a crow.
But if the reason was fuse like kernel-free FS (no one said that
though) then its better to do it as a separate project.

> especially for tests.

It depends whats being tested kernel OR progs? Its kernel not progs.
Automatic will keep default feature constant for a given kernel
version. Further, for testing using a known set of options is even
better.

> A lot of btrfs-progs change, like recent disabling mixed-bg for small
> volume has already cause regression in generic/077 testcase.
> And Dave is already fed up with such problem from btrfs...

I don't know what's the regression about. But in my experience with
some xfstest test cases.. xfstests depend too much on cli output
strings which is easy thing to do but a wrong approach.
Those cli outputs and its format are NOT APIs, those are UIs. Instead
it should have used return code/ FS test interface. This will let
developers with free hands to change, otherwise you need to update the
test cases every time you change the cli _output_.

> Especially such auto-detection will make default behavior more unstable,
> at least not a good idea for me.

As above. We design with end-user and their use cases in mind. Not for
a test suite. If test suite breaks.. fix it.

Thanks, Anand

> Beside this, I'm curious how other filesystm user tools handle such
> kernel mismatch, or do they?

> Thanks,
> Qu
>
>
>>
>> First of all to let user know what features was supported at what kernel
>> version. Patch 1/7 updates -O list-all which will list the feature with
>> version.
>>
>> As we didn't maintain the sysfs and progs feature names consistent, so
>> to avoid confusion Patch 2/7 displays sysfs feature name as well again
>> in the list-all output.
>>
>> Next, Patch 3,4,5/7 are helper functions.
>>
>> Patch 6,7/7 provides the -O comp=<version> for mkfs.btrfs and
>> btrfs-convert respectively
>>
>> Thanks, Anand
>>
>> Anand Jain (7):
>>    btrfs-progs: show the version for -O list-all
>>    btrfs-progs: add kernel alias for each of the features in the list
>>    btrfs-progs: make is_numerical non static
>>    btrfs-progs: check for numerical in version_to_code()
>>    btrfs-progs: introduce framework version to features
>>    btrfs-progs: add -O comp= option for mkfs.btrfs
>>    btrfs-progs: add -O comp= option for btrfs-convert
>>
>>   btrfs-convert.c | 21 +++++++++++++++++++++
>>   cmds-replace.c  | 11 -----------
>>   mkfs.c          | 24 ++++++++++++++++++++++--
>>   utils.c         | 58
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++-----
>>   utils.h         |  2 ++
>>   5 files changed, 98 insertions(+), 18 deletions(-)
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html