linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Qu Wenruo <quwenruo@cn.fujitsu.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 0/4] Fix for btrfs-convert chunk type and fsck support
Date: Tue, 29 Sep 2015 11:31:22 +0200	[thread overview]
Message-ID: <20150929093121.GV11442@suse.cz> (raw)
In-Reply-To: <56064FBA.4000809@gmx.com>

On Sat, Sep 26, 2015 at 03:56:42PM +0800, Qu Wenruo wrote:
> > So can we do it like this:
> >
> > 1) enable support for mixed bg in convert
> > 2) implement mixed -> split conversion in balance
> > 3) force convert to do mixed bgs by default
> >
> > The conversion from/to mixed would be good on it's own but may not be
> > trivial to implement.
> 
> Agreed, and consider it is kernel code, it will be much harder to 
> code/debug.

I've looked into that some time ago. The relocation code seems ready for
that, the data and metadata blocks are filtered separately from the
given chunk and moved to the new chunk. We need to propagate the request
to convert from/to mixed-bg through the balance filters.

> > If the main concern about result of conversion is
> > bad bg layout, I'd say that we rely on balance to reshuffle the bgs to
> > make the filesystem more up to the desired layout.
> 
> That's OK.
> At least we don't need to implement kernel convert support for mixed bg.
> 
> I'll implement both mixed bg and separate one and allow user to choose.
> 
> And for extreme case, if we can't allocate any metadata chunk larger 
> than 16M, either info user and exit or do automatic mixed-bg conversion 
> if no conflicting options.

We can possibly scan the image first for the available holes and then
decide if it's feasible to do the conversion with the requested fs features.

  reply	other threads:[~2015-09-29  9:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-10  2:34 [PATCH 0/4] Fix for btrfs-convert chunk type and fsck support Qu Wenruo
2015-09-10  2:34 ` [PATCH v2 1/5] btrfs-progs: fsck: Add check for extent and parent chunk type Qu Wenruo
2015-09-10  2:34 ` [PATCH v2 2/5] btrfs-progs: utils: Check nodesize against features Qu Wenruo
2015-09-10  2:34 ` [PATCH v2 3/5] btrfs-progs: convert: force convert to used mixed block group Qu Wenruo
2015-09-10  2:34 ` [PATCH v2 4/5] btrfs-progs: util: add parameter for btrfs_list_all_fs_features Qu Wenruo
2015-09-10  2:37 ` [PATCH v2 5/5] btrfs-progs: convert-test: Disable different nodesize test Qu Wenruo
2015-09-11 14:56 ` [PATCH 0/4] Fix for btrfs-convert chunk type and fsck support David Sterba
2015-09-11 15:23   ` Qu Wenruo
2015-09-24  1:18   ` Qu Wenruo
2015-09-25 15:19     ` David Sterba
2015-09-26  7:56       ` Qu Wenruo
2015-09-29  9:31         ` David Sterba [this message]
2015-09-25 15:49 ` David Sterba
  -- strict thread matches above, loose matches on Subject: below --
2015-09-09  8:49 Qu Wenruo

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=20150929093121.GV11442@suse.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=quwenruo@cn.fujitsu.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 NNTP newsgroup(s).