From: HAN Yuwei <hrx@bupt.moe>
To: kreijack@inwind.it, dsterba@suse.cz
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: mkfs.btrfs enabled RST by default casuing unable to mount on stable kernel
Date: Thu, 25 Apr 2024 11:07:25 +0800 [thread overview]
Message-ID: <B9DB8244635257EC+464c494f-aa0f-44b2-8026-f20035df9f9d@bupt.moe> (raw)
In-Reply-To: <04a4bfa7-9596-424d-afb0-c9ab9458f969@libero.it>
[-- Attachment #1.1: Type: text/plain, Size: 3766 bytes --]
在 2024/4/25 3:57, Goffredo Baroncelli 写道:
> On 24/04/2024 18.15, HAN Yuwei wrote:
>>
>> 在 2024/4/24 17:48, David Sterba 写道:
>>> On Wed, Apr 24, 2024 at 01:45:24PM +0800, HAN Yuwei wrote:
>>>> I have found incompatibility issue on btrfs-prog & kernel. btrfs-progs
>>>> is v6.7.1, kernel is 6.7.5-aosc-main.
>>>>
>>>> Using this command to create btrfs volume:
>>>> # mkfs.btrfs -f -d raid10 -m raid1c4 -s 16k -L HYWDATA_ZONED_TEST
>>>> /dev/sdb /dev/sdc /dev/sdd /dev/sde
>>>>
>>>> When mounting, dmesg said:
>>>> [ 329.071403] BTRFS info (device sdb): first mount of filesystem
>>>> 7b4f2ca6-efe3-48d9-81f6-ba65a00db85e
>>>> [ 329.080422] BTRFS info (device sdb): using crc32c (crc32c-generic)
>>>> checksum algorithm
>>>> [ 329.088222] BTRFS info (device sdb): using free space tree
>>>> [ 329.093673] BTRFS error (device sdb): cannot mount because of
>>>> unknown
>>>> incompat features (0x5b41)
>>>> [ 329.102442] BTRFS error (device sdb): open_ctree failed
>>>>
>>>> dump-super said:
>>>> [...]
>>>> incompat_flags 0x5b41
>>>> ( MIXED_BACKREF |
>>>> EXTENDED_IREF |
>>>> SKINNY_METADATA |
>>>> NO_HOLES |
>>>> RAID1C34 |
>>>> ZONED |
>>>> RAID_STRIPE_TREE )
>>>> [...]
>>>>
>>>>
>>>> RAID_STRIPE_TREE need CONFIG_BTRFS_DEBUG to be supported and this
>>>> feature flag is disabled on most distributions. I hope RST can be
>>>> disabled by default on btrfs-progs.
>>> IMO this works as intended. Features may be enabled ahead of time in
>>> btrfs-progs due to early testing and not requiring the experimental
>>> build. The experimental status of progs features is about completeness
>>> of the implementation, so if mkfs creates a filesystem with RST then it
>>> could be enabled.
>> If due to early testing, btrfs-progs could have --experimental option
>> to enable it instead of
>>
>> enabling it by default which would causing confusion to normal users.
>> For experienced user who wants to test new feature, we can hint them
>> to use this option when needed.
>>
>> e.g.
>>
>> # mkfs.btrfs -f -d raid10 -m raid1c4 -s 16k
>> can't use raid10, this is a experimental feature, use --experimental
>> if you really want it.
>>
>> # mkfs.btrfs -f -d raid10 -m raid1c4 -s 16k --experimental
>>
>> [succeed]
>>
>>> The kernel support is still missing some features and there are some
>>> known bugs, this is conveniently hidden behind the DEBUG option so it
>>> does not affect distributions.
>>>
>>> However it seems that the documentation is not clear about that and the
>>> status page should be updated.
>>>
>
> I think that the problem is the following: if you want to use a "zoned
> device"
> and a "raid device", you NEED a raid-stripe-tree.
> In fact by default the RST is not enabled, but it is pulled if we have
> a zoned device and a raid10.
>
> So it is not a problem of btrfs-progs itself.
>
> I think that btrfs.mkfs should be more verbose about pulling incomapt
> feature as a dependency.
>
>
I think that btrfs-progs could require user to explicitly introduce
features which current stable kernel may not enabled by default instead
of being more verbose in output.
Because users may 1. don't read output 2. are using tty which would
truncate their output. Making this explicitly is better than surprising
users afterwards.
HAN Yuwei
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
prev parent reply other threads:[~2024-04-25 3:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 5:45 mkfs.btrfs enabled RST by default casuing unable to mount on stable kernel HAN Yuwei
2024-04-24 9:48 ` David Sterba
2024-04-24 16:15 ` HAN Yuwei
2024-04-24 19:57 ` Goffredo Baroncelli
2024-04-25 3:07 ` HAN Yuwei [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=B9DB8244635257EC+464c494f-aa0f-44b2-8026-f20035df9f9d@bupt.moe \
--to=hrx@bupt.moe \
--cc=dsterba@suse.cz \
--cc=kreijack@inwind.it \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).