On Sun, May 17, 2015 at 08:19:48AM +0000, Duncan wrote: > Philip Seeger posted on Sun, 17 May 2015 03:53:20 +0200 as excerpted: > > > > On 05/10/2015 04:58 PM, Philip Seeger wrote: > >> > >> Forgot to mention kernel version: Linux 4.0.1-1-ARCH > >> > >> $ sudo btrfs fi show Label: none uuid: > >> 3e8973d3-83ce-4d93-8d50-2989c0be256a > >> Total devices 1 FS bytes used 19.87GiB > >> devid 1 size 45.00GiB used 21.03GiB path /dev/sda1 > >> > >> btrfs-progs v3.19.1 > >> > > I think I forgot to mention that this btrfs filesystem was converted > > from ext4 (not initially created as btrfs). > > Could this cause this corruption? > > > > Also, does this df output look weird to anyone, shouldn't metadata be > > duplicated? > > # btrfs fi df / > > Data, single: total=21.00GiB, used=20.82GiB > > System, single: total=32.00MiB, used=4.00KiB > > Metadata, single: total=1.25GiB, used=901.21MiB > > GlobalReserve, single: total=304.00MiB, used=0.00B > > [Reordered to standard quote/reply order, so replies have proper > context. Top posting... not so fun to reply to! =:^( ] > > I can't answer the corruption bit, but answering the df metadata > question... > > Normally, btrfs on a single device defaults to dup metadata type, single > data type. The one /normal/ exception to that is when mkfs.btrfs detects > an ssd, where it defaults to single data due to ssd firmware often > canceling out the intended redundancy of dup anyway.[1] > > However, conversion from ext* is a bit of a different ball game, and > while it /should/ default to dup metadata as well, on 4.0 and into 4.1-rcs > as a proper fix hasn't been posted, there's a balance-conversion bug > that's keeping type conversion from occurring, both in the normal btrfs > balance convert case and in the ext* conversion case. Thus, ext* > conversions remain metadata-single mode and cannot be converted to > metadata-dup until this bug is fixed. > > I said that a /proper/ fix hasn't yet been posted. There has been a > bisect trace to the commit that killed balance-convert, and that can be > reverted, as I guess some distros are doing in their current releases. > However, that commit happened to fix an ext* to btrfs conversion fault, > that would cause ext* conversions to fail entirely. So reverting that > commit does fix normal btrfs balance conversions, but it breaks the > ability to convert from ext* at all. I don't know when /that/ was > broken, but apparently it was further back. > > So right now, the only way to get a desired btrfs chunk redundancy type > is to use mkfs.btrfs to create it that way in the first place. Which > means no ext* conversion unless you're happy with single-data/single- > metadata, since that's what it ends up with, and balance-convert is ATM > currently broken and can't convert to other redundancy types. > > Well, unless you want to do the ext* to btrfs convert with the current > tools as they are (with the commit in question so the ext*-conversion > actually works), then rebuild with that commit reverted, so balance- > convert works... Duncan is referring to the commit reverted here: https://patchwork.kernel.org/patch/6238111/ Just to clarify, reverting 2f0810880f082fa8ba66ab2c33b02e4ff9770a5e does not break ext4 conversion. If you revert it, you can btrfs-convert, do a btrfs balance to finalize the conversion, then do another btrfs balance -dconvert=... -mconvert=... to convert the profile. I should have been clearer in that other thread: conversion from ext4 to Btrfs works, its just that the commit that caused the regression did not actually accomplish what it set out to do: allow converting the data/metadata profile of a freshly btrfs-converted ext4 filesystem. -- Omar -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
