From: Goffredo Baroncelli <kreijack@libero.it>
To: Qu Wenruo <wqu@suse.com>, David Sterba <dsterba@suse.cz>
Cc: HAN Yuwei <hrx@bupt.moe>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs-progs: fsfeatures: hide RST behind experimental builds
Date: Wed, 24 Apr 2024 21:58:12 +0200 [thread overview]
Message-ID: <2864ff12-1d6a-4559-9f42-0cbcf7eed74d@libero.it> (raw)
In-Reply-To: <d0b14c11-c224-4fb4-b9d6-ad7bfa0ecbba@libero.it>
On 24/04/2024 21.30, Goffredo Baroncelli wrote:
> On 24/04/2024 07.49, Qu Wenruo wrote:
>> [BUG]
>> There is a report that with v6.7.1 btrfs-progs, `mkfs.btrfs -O rst`, but
>> kernel 6.7/6.8 are unable to mount it at all.
>>
>> [CAUSE]
>> Although the feature string states the raid-stripe-tree feature is
>> supported since v6.7 kernel, it's not correct.
>> Only debug kernel with CONFIG_BTRFS_DEBUG would support the RST feature.
>>
>> Thus RST is still considered experimental.
>>
>> [FIX]
>> Move the RST mkfs features back to experimental.
>>
>> This patch would only hide the RST features from 'mkfs -O' options, the
>> existing supporting code for RST would still be there, thus
>> non-experimental build of `btrfs check` can still verify a btrfs with
>> RST.
>>
>> Reported-by: HAN Yuwei <hrx@bupt.moe>
>> Fixes: b421fdff9574 ("btrfs-progs: move raid-stripe-tree and squota build out of experimental")
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>> common/fsfeatures.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/common/fsfeatures.c b/common/fsfeatures.c
>> index c5e81629ccea..7aaddab6a192 100644
>> --- a/common/fsfeatures.c
>> +++ b/common/fsfeatures.c
>> @@ -222,6 +222,7 @@ static const struct btrfs_feature mkfs_features[] = {
>> VERSION_NULL(default),
>> .desc = "block group tree, more efficient block group tracking to reduce mount time"
>> },
>> +#if EXPERIMENTAL
>> {
>> .name = "rst",
>> .incompat_flag = BTRFS_FEATURE_INCOMPAT_RAID_STRIPE_TREE,
>> @@ -238,6 +239,7 @@ static const struct btrfs_feature mkfs_features[] = {
>> VERSION_NULL(default),
>> .desc = "raid stripe tree, enhanced file extent tracking"
>> },
>> +#endif
>> {
>> .name = "squota",
>> .incompat_flag = BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA,
>
> I am bit confused.
Ignore this email.
>
> The Han report say that the problem is due to the fact that the option is enabled by *default*.
>
> So way we should remove (from the binary) this option at all ? Shouldn't be enough to remove it from the options enabled by default ?
>
> Something like:
>
> - VERSION_TO_STRING2(compat, 6,7),
> - VERSION_NULL(safe),
>
> + VERSION_NULL(compat),
>
> + VERSION_TO_STRING2(safe, 6,7),
>
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
prev parent reply other threads:[~2024-04-24 19:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 5:49 [PATCH] btrfs-progs: fsfeatures: hide RST behind experimental builds Qu Wenruo
2024-04-24 7:48 ` Johannes Thumshirn
2024-04-24 19:30 ` Goffredo Baroncelli
2024-04-24 19:58 ` Goffredo Baroncelli [this message]
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=2864ff12-1d6a-4559-9f42-0cbcf7eed74d@libero.it \
--to=kreijack@libero.it \
--cc=dsterba@suse.cz \
--cc=hrx@bupt.moe \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@suse.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).