From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <wqu@suse.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Seed device is broken, again.
Date: Fri, 25 Feb 2022 12:47:29 +0100 [thread overview]
Message-ID: <20220225114729.GE12643@twin.jikos.cz> (raw)
In-Reply-To: <88176dfc-2500-1e9c-bac0-5e293b2c0b5c@suse.com>
On Fri, Feb 25, 2022 at 06:08:20PM +0800, Qu Wenruo wrote:
> Hi,
>
> The very basic seed device usage is broken again:
>
> mkfs.btrfs -f $dev1 > /dev/null
> btrfstune -S 1 $dev1
> mount $dev1 $mnt
> btrfs dev add $dev2 $mnt
> umount $mnt
>
>
> I'm not sure how many guys are really using seed device.
>
> But I see a lot of weird operations, like calling a definite write
> operation (device add) on a RO mounted fs.
That's how the seeding device works, in what way would you want to do
the ro->rw change?
> Can we make at least the seed sprouting part into btrfs-progs instead?
How? What do you mean? This is an in kernel operation that is done on a
mounted filesystem, progs can't do that.
> And can seed device even support the upcoming extent-tree-v2?
I should, it operates on the device level.
> Personally speaking I prefer to mark seed device deprecated completely.
If we did that with every feature some developer does not like we'd have
nothing left you know. Seeding is a documented usecase, as long as it
works it's fine to have it available.
> The call trace:
>
> assertion failed: sb_write_started(fs_info->sb), in
> fs/btrfs/volumes.c:3244
Yeah the asserts now appear and we need to fix the write annotations
first. I've moved the patches out of misc-next again, it's now only in
for-next so it does not block testing.
next prev parent reply other threads:[~2022-02-25 11:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 10:08 Seed device is broken, again Qu Wenruo
2022-02-25 11:39 ` Filipe Manana
2022-02-25 11:47 ` David Sterba [this message]
2022-02-25 13:36 ` Qu Wenruo
2022-02-25 19:18 ` Omar Sandoval
2022-02-27 23:56 ` Qu Wenruo
2022-02-28 2:01 ` Anand Jain
2022-02-28 2:35 ` Qu Wenruo
2022-02-28 3:24 ` Anand Jain
2022-02-28 3:27 ` Qu Wenruo
2022-02-28 18:40 ` David Sterba
2022-03-01 0:13 ` Qu Wenruo
2022-03-01 1:49 ` Chris Murphy
2022-03-01 17:09 ` David Sterba
2022-03-02 0:00 ` Qu Wenruo
2022-03-01 1:44 ` Chris Murphy
2022-03-02 10:09 ` Neal Gompa
2022-02-25 12:00 ` Nikolay Borisov
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=20220225114729.GE12643@twin.jikos.cz \
--to=dsterba@suse.cz \
--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