Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: btrfs <linux-btrfs@vger.kernel.org>, David Sterba <dsterba@suse.com>
Subject: Re: Ideas for btrfs-convert fix(or rework)
Date: Tue, 10 Nov 2015 14:08:55 +0500	[thread overview]
Message-ID: <20151110140855.3ae7297c@natsu> (raw)
In-Reply-To: <5641A7DA.6010102@gmx.com>

[-- Attachment #1: Type: text/plain, Size: 3202 bytes --]

On Tue, 10 Nov 2015 16:16:26 +0800
Qu Wenruo <quwenruo.btrfs@gmx.com> 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. After all the rebalancing, I currently have:

Data, single: total=8.37TiB, used=7.50TiB
System, DUP: total=32.00MiB, used=592.00KiB
Metadata, DUP: total=8.00GiB, used=6.42GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

> > But as we know recently there were reports that it now causes corruption or
> > does not work. So I wonder what happened that broke it, and is there really no
> > simpler fix? Even if requiring the user to balance to get rid of the bloated
> > Metadata like I had to.
> >
> 
> Yes, current btrfs-convert has problem on marking chunk meta or data.
> Resulting some data extents may lay in metadata chunk, and vice verse.
> At least it won't pass latest btrfsck.
> 
> In that incorrect chunk layout, I'm not surprised any thing go wrong.

Made an experiment:

# dd if=/dev/zero bs=1M count=1 seek=100000 of=100G
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.0023896 s, 439 MB/s

# losetup /dev/loop7 100G

# mkfs.ext4 /dev/loop7 

// Success

# mount /dev/loop7 /mnt/tmp1/

// Copy some files there

# df -h /mnt/tmp1/
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop7       96G  2.6G   89G   3% /mnt/tmp1

# umount /mnt/tmp1/

# btrfs-convert -d /dev/loop7 
creating btrfs metadata.
creating ext2fs image file.
cleaning up system chunk.
conversion complete.

# mount /dev/loop7 /mnt/tmp1/

# btrfs fi df /mnt/tmp1/
Data, single: total=65.00GiB, used=1.32GiB
System, single: total=32.00MiB, used=12.00KiB
Metadata, single: total=32.63GiB, used=2.91GiB
GlobalReserve, single: total=92.00MiB, used=0.00B

# btrfs sub del /mnt/tmp1/ext2_saved
Transaction commit: none (default)
Delete subvolume '/mnt/tmp1/ext2_saved'

# btrfs fi df /mnt/tmp1/
Data, single: total=10.00GiB, used=120.12MiB
System, single: total=32.00MiB, used=4.00KiB
Metadata, single: total=4.00GiB, used=2.37GiB
GlobalReserve, single: total=52.00MiB, used=0.00B

// It has 2.6 GB of files, and most of them are now accounted as "Metadata".

# btrfs fi balance start -m /mnt/tmp1/
Done, had to relocate 5 out of 7 chunks

// They are now reclassified as data:

# btrfs fi df /mnt/tmp1/
Data, single: total=10.00GiB, used=2.49GiB
System, single: total=32.00MiB, used=4.00KiB
Metadata, single: total=1.00GiB, used=468.00KiB
GlobalReserve, single: total=4.00MiB, used=0.00B

// Unmount, mount, checked all files integrity with 'cfv', all files are
present and there is no corruption.

So this behaves just like I remember it to, after conversion at first a large
part of the data will show up as Metadata, but a balance fixes that. And most
importantly no corruption issues. Maybe it's just because this is only a small
test FS, but my production one earlier went through the same process without
problems as well.

Using btrfs-tools v3.17 and kernel 3.18.21

-- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2015-11-10  9:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-10  6:27 Ideas for btrfs-convert fix(or rework) Qu Wenruo
2015-11-10  7:55 ` Roman Mamedov
2015-11-10  8:16   ` Qu Wenruo
2015-11-10  9:08     ` Roman Mamedov [this message]
2015-11-10  9:18       ` Qu Wenruo
2015-11-10 10:31         ` Duncan
2015-11-12 10:23           ` Vytautas D
2015-11-12 13:27             ` Austin S Hemmelgarn
2015-11-12 14:09               ` Roman Mamedov
2015-11-12 14:38                 ` Austin S Hemmelgarn
2015-11-13  6:41                   ` Duncan
2015-11-16 17:46 ` David Sterba
2015-11-17  0:42   ` 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=20151110140855.3ae7297c@natsu \
    --to=rm@romanrm.net \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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