linux-kernel - Re: btrfs balance 4.0 regression?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150517084642.GA14149@mew>
Date:	Sun, 17 May 2015 01:46:42 -0700
From:	Omar Sandoval <osandov@...ndov.com>
To:	linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: btrfs balance 4.0 regression?

On Thu, May 14, 2015 at 05:33:29PM -0700, Omar Sandoval wrote:
> On Fri, May 15, 2015 at 12:15:06AM +0000, Duncan wrote:
> > Josh Boyer posted on Thu, 14 May 2015 08:43:25 -0400 as excerpted:
> > 
> > > Hi Omar and Chris,
> > > 
> > > We have a bug reported [1] against 4.0 saying that btrfs balance is
> > > broken.  The reporter found a revert patch that Omar sent [2] to revert
> > > commit 2f0810880.  Looking in Linus' latest tree, I don't see that
> > > revert and I don't immediately see a patch to fix the issue Omar
> > > reported either.
> > > 
> > > Do either of you know if this is still an issue?  If not, which commit
> > > was it fixed by?
> > > 
> > > josh
> > > 
> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1217191
> > > [2] https://patchwork.kernel.org/patch/6238111/
> > 
> > Still an issue, officially as of dev comments a day or two ago, at least.
> 
> Yup, Chris says he has a proper fix but it hasn't hit the list yet.
> 
> > From various comments including from Chris Mason directly, the devs are 
> > aware of it, but (from a non-dev list-regular perspective) there's a 
> > seeming reluctance to simply apply the revert patch.  Not being a dev I 
> > can't explain why tho I can speculate that the patch is logically correct 
> > and simply triggers this other bug.  But further patches have yet to 
> > appear.
> > 
> > Part of the problem may be a bit of confusion as some of the devs 
> > evidently thought the revert patch fixed the problem and hadn't been 
> > worrying about it until others pointed out the revert hadn't been applied 
> > and the problem thus remained.
> > 
> > So as of now, the choice appears to be broken balance-convert with the 
> > current code, or broken ext*-convert with that patch reverted.  Both 
> > cases aren't entirely common, so I guess it's up to you which you want to 
> > break ATM.
> 
> Actually, ext4 convert is broken anyways (with irrelevant output
> elided):

(I realize that I was being a bit too alarmist here. Reposting a message
from another thread clarifying.)

"""
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/