On Tue, Nov 10, 2015 at 02:27:41PM +0800, Qu Wenruo wrote:
> [[FIX IDEA]]
> 1. Too many patches
Not percieved as a problem as long as the patches are well separated and
reviewable. If you prefer reasonably many preparatory and trivial
patches, then be it.
> 2. superblock reserve is d*mning hard,
David Sterba wrote on 2015/11/16 18:46 +0100:
On Tue, Nov 10, 2015 at 02:27:41PM +0800, Qu Wenruo wrote:
[[FIX IDEA]]
1. Too many patches
Not percieved as a problem as long as the patches are well separated and
reviewable. If you prefer reasonably many preparatory and trivial
patches, then
[ resending as it didnt get through. ]
I got different opinion. btrfs-convert is something that
brought me to btrfs. While there are other bugs to fix, someone
dedicating time to fix btrfs-convert is of high interest to me.
Sending right message to community, might make some rolling distros to
Austin S Hemmelgarn posted on Thu, 12 Nov 2015 09:38:03 -0500 as
excerpted:
> I'm not arguing that [btrfs-convert] should just go away, I'm trying to
> argue that it shouldn't be a development priority if it works correctly.
Agreed.
If you go back to my reply that started this subthread, the
On 2015-11-12 09:09, Roman Mamedov wrote:
On Thu, 12 Nov 2015 08:27:49 -0500
Austin S Hemmelgarn wrote:
know of (Arch and Gentoo), because the very fact that you installed a
system with either one means that you are fully capable of backing up
your data, and
On 2015-11-12 05:23, Vytautas D wrote:
[ resending as it didnt get through. ]
I got different opinion. btrfs-convert is something that
brought me to btrfs. While there are other bugs to fix, someone
dedicating time to fix btrfs-convert is of high interest to me.
Sending right message to
On Thu, 12 Nov 2015 08:27:49 -0500
Austin S Hemmelgarn wrote:
> know of (Arch and Gentoo), because the very fact that you installed a
> system with either one means that you are fully capable of backing up
> your data, and reprovisioning the system using BTRFS instead of
On Tue, 10 Nov 2015 16:16:26 +0800
Qu Wenruo wrote:
> So if things are correct, the btrfs you converted should still be in
> mixed-bg mode.
> A recent 'btrfs fi df' command should show things like:
> Data+Metadata, DUP: total=512.00MiB, used=68.23MiB
Actually not quite.
Qu Wenruo posted on Tue, 10 Nov 2015 17:18:02 +0800 as excerpted:
> Yes, some problem can be fixed by such balance, as after balance, data
> and metadata will be relocated to correct new chunks.
>
> But there may be a lot of hidden bugs here.
> And we can't ignore such malfunction just because
Roman Mamedov wrote on 2015/11/10 14:08 +0500:
On Tue, 10 Nov 2015 16:16:26 +0800
Qu Wenruo wrote:
So if things are correct, the btrfs you converted should still be in
mixed-bg mode.
A recent 'btrfs fi df' command should show things like:
Data+Metadata, DUP:
Roman Mamedov wrote on 2015/11/10 12:55 +0500:
On Tue, 10 Nov 2015 14:27:41 +0800
Qu Wenruo wrote:
But without such work, btrfs-convert will always be a mess and no
real support for balance.
I wonder, what happened to the current btrfs-convert?
Perhaps a
Hi all,
Someone may already knows, I'm recently trying to fix(or rework) the old
btrfs-convert, to allow it to support separate data and meta chunks.
[[FIX IDEA]]
The overall idea is quite simple and straight forward:
Separate meta/sys chunk at very *beginning*, then insert data chunks to
On Tue, 10 Nov 2015 14:27:41 +0800
Qu Wenruo wrote:
> But without such work, btrfs-convert will always be a mess and no
> real support for balance.
I wonder, what happened to the current btrfs-convert?
Perhaps a couple of years ago I converted a 7TB and ~70%
13 matches
Mail list logo