public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
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.


  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