From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: dsterba@suse.cz, Anand Jain <anand.jain@oracle.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version
Date: Mon, 23 Nov 2015 15:14:44 -0500 [thread overview]
Message-ID: <565373B4.2070907@gmail.com> (raw)
In-Reply-To: <20151123175608.GI31035@twin.jikos.cz>
[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]
On 2015-11-23 12:56, David Sterba wrote:
> On Mon, Nov 23, 2015 at 08:56:13PM +0800, Anand Jain wrote:
>> Btrfs-progs is a tool for the btrfs kernel and we hope latest btrfs-progs
>> be compatible w any set of older/newer kernels.
>>
>> So far mkfs.btrfs and btrfs-convert sets the default features, for eg,
>> skinny-metadata even if the running kernel does not supports it, and
>> so the mount fails on the running.
>
> So the default behaviour of mkfs will try to best guess the feature set
> of currently running kernel. I think this is is the most common scenario
> and justifies the change in default behaviours.
I feel that Christoph's suggestion in the other sub-thread to have it
spit out a notice that it disabled something because of the kernel it's
running on is worth adding also. We should probably also spit out a
warning if the user asks for a feature that isn't supported on the
current kernel (but still let them create the filesystem regardless).
>
> For the other cases I'd like to introduce some human-readable shortcuts
> to the --features option. Eg. 'mkfs.btrfs -O compat-3.2' will pick all
> options supported by the unpatched mainline kernel of version 3.2. This
> would be present for all version, regardless if there was a change in the
> options or not.
>
> Similarly for convenience, add 'running' that would pick the options
> from running kernel but will be explicit.
Is the intent to enable stuff that the devs consider stable that's
supported by the running kernel, or all the features supported by the
running kernel? It's probably best to use the first as the defaults,
and then have an option to pull in everything the running kernel
supports (possibly name that option something like 'running-all').
>
> A remaining option should override the 'running' behaviour and pick the
> latest mkfs options. Naming it 'defaults' sounds a bit ambiguous so the
> name is yet to be determined.
Maybe something like 'recommended' or 'suggested'?
It might also be nice to have an option to tell it to turn on everything
the tools support (possibly call that one something like
'max-features'), though this is probably less useful due to the fact
that most mkfs features in BTRFS are incompat features.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
next prev parent reply other threads:[~2015-11-23 20:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 12:56 [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version Anand Jain
2015-11-23 12:56 ` [PATCH v2 1/5] btrfs-progs: introduce framework to check kernel supported features Anand Jain
2015-11-24 14:39 ` Mike Fleetwood
2015-11-24 20:21 ` Austin S Hemmelgarn
2015-11-26 17:38 ` David Sterba
2015-11-30 12:30 ` Austin S Hemmelgarn
2015-11-25 10:58 ` [PATCH v3 " Anand Jain
2015-11-23 12:56 ` [PATCH v2 2/5] btrfs-progs: add framework to check features supported by sysfs Anand Jain
2015-11-23 12:56 ` [PATCH v2 3/5] btrfs-progs: kernel based default features for mkfs Anand Jain
2015-11-23 15:57 ` Christoph Anton Mitterer
2015-11-23 16:05 ` Austin S Hemmelgarn
2015-11-23 16:14 ` Christoph Anton Mitterer
2015-11-23 16:55 ` Austin S Hemmelgarn
2015-11-23 12:56 ` [PATCH v2 4/5] btrfs-progs: kernel based default features for btrfs-convert Anand Jain
2015-11-23 12:56 ` [PATCH 5/5] btrfs-progs: add warning when we fail to read sysfs or version Anand Jain
2015-11-23 17:56 ` [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version David Sterba
2015-11-23 20:14 ` Austin S Hemmelgarn [this message]
2015-11-24 6:29 ` Duncan
2015-11-24 13:22 ` Anand Jain
2015-12-04 1:44 ` Liu Bo
2015-12-04 2:08 ` Qu Wenruo
2015-12-04 2:53 ` Liu Bo
2015-12-04 3:57 ` Qu Wenruo
2015-12-04 18:23 ` Liu Bo
2015-12-04 14:19 ` David Sterba
2015-12-05 5:12 ` Anand Jain
2015-11-24 13:04 ` Anand Jain
2016-11-08 13:14 ` Anand Jain
2016-11-14 12:13 ` David Sterba
2016-11-22 8:54 ` Anand Jain
2016-11-22 13:16 ` David Sterba
2016-11-23 3:00 ` Anand Jain
2016-11-23 10:31 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=565373B4.2070907@gmail.com \
--to=ahferroin7@gmail.com \
--cc=anand.jain@oracle.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).