All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: dsterba@suse.cz, Mike Fleetwood <mike.fleetwood@googlemail.com>,
	Anand Jain <anand.jain@oracle.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH v2 1/5] btrfs-progs: introduce framework to check kernel supported features
Date: Mon, 30 Nov 2015 07:30:10 -0500	[thread overview]
Message-ID: <565C4152.8040103@gmail.com> (raw)
In-Reply-To: <20151126173850.GV31035@twin.jikos.cz>

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

On 2015-11-26 12:38, David Sterba wrote:
> On Tue, Nov 24, 2015 at 03:21:19PM -0500, Austin S Hemmelgarn wrote:
>>> I think you mean 2.6.37 here.
>>> 67377734fd24c3 "Btrfs: add support for mixed data+metadata block groups"
>> This brings up a rather important question:
>> Should compat-X.Y mean features that were considered usable in that
>> version, or everything that version offered?  I understand wanting
>> consistency with the kernel versions, but we shouldn't be creating
>> filesystems that we know will break on the specified kernel even if it
>> is mountable on it.
>
> IMO compat refers to the compatibility feature bits so it's whether the
> filesystem is mountable on a given version. Usability can be subjective.
> I assume the kernel versions in wide use match some of the long term
> branches. If it's k.org, we can submit the fixes and distros update
> their long term branches.
My point was that if we know that there's a significant chance of either 
data corruption or a kernel crash when using a given feature with a 
given kernel, we should not turn on that feature for that kernel.  For 
every other project I've ever seen, compatible means that you can be 
fairly certain that it won't crash, and won't destroy data.  There is no 
excuse for knowingly making filesystems that will break the system.

Also, expecting the distros to keep up with development given the pace 
at which BTRFS is moving is not all that realistic.  Secondarily, at 
least Ubuntu has a habit of picking kernel versions that aren't marked 
LTS by kernel.org.
>
> A table of "is the feature usable" would be interesting but I think it's
> for wiki.
I'd say it would be a lot more helpful in the manpage than in the wiki 
(if you're reprovisioning a system, you don't necessarily have access to 
the wiki).


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-11-30 12:30 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 [this message]
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
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=565C4152.8040103@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mike.fleetwood@googlemail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.