From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cn.fujitsu.com ([59.151.112.132]:40848 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751128AbcCaA2s (ORCPT ); Wed, 30 Mar 2016 20:28:48 -0400 Subject: Re: "bad metadata" not fixed by btrfs repair To: Henk Slager References: <20160328143714.GZ10135@torres.zugschlus.de> <56F98784.8090700@gmail.com> <20160329064351.GA28990@torres.zugschlus.de> <56FB7983.2060608@cn.fujitsu.com> CC: Marc Haber , linux-btrfs From: Qu Wenruo Message-ID: <56FC6F3B.9050602@cn.fujitsu.com> Date: Thu, 31 Mar 2016 08:28:43 +0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: Henk Slager wrote on 2016/03/30 16:03 +0200: > On Wed, Mar 30, 2016 at 9:00 AM, Qu Wenruo wrote: >> First of all. >> >> The "crossing stripe boundary" error message itself is *HARMLESS* for recent >> kernels. >> >> It only means, that metadata extent won't be checked by scrub on recent >> kernels. >> Because scrub by its codes, has a limitation that, it can only check tree >> blocks which are inside a 64K block. >> >> Old kernel won't have anything wrong, until that tree block is being >> scrubbed. >> When scrubbed, old kernel just BUG_ON(). >> >> Now recent kernel will handle such limitation by checking extent allocation >> and avoid crossing boundary, so new created fs with new kernel won't cause >> such error message at all. >> >> But for old created fs, the problem can't be avoided, but at least, new >> kernels will not BUG_ON() when you scrub these extents, they just get >> ignored (not that good, but at least no BUG_ON). >> >> And new fsck will check such case, gives such warning. >> >> Overall, you're OK if you are using recent kernels. >> >> Marc Haber wrote on 2016/03/29 08:43 +0200: >>> >>> On Mon, Mar 28, 2016 at 03:35:32PM -0400, Austin S. Hemmelgarn wrote: >>>> >>>> Did you convert this filesystem from ext4 (or ext3)? >>> >>> >>> No. >>> >>>> You hadn't mentioned what version of btrfs-progs you're using, and that >>>> is >>>> somewhat important for recovery. I'm not sure if current versions of >>>> btrfs >>>> check can fix this issue, but I know for a fact that older versions >>>> (prior >>>> to at least 4.1) can not fix it. >>> >>> >>> 4.1 for creation and btrfs check. >> >> >> I assume that you have run older kernel on it, like v4.1 or v4.2. >> >> In those old kernels, it lacks the check to avoid such extent allocation >> check. >> >>> >>>> As far as what the kernel is involved with, the easy way to check is if >>>> it's >>>> operating on a mounted filesystem or not. If it only operates on mounted >>>> filesystems, it almost certainly goes through the kernel, if it only >>>> operates on unmounted filesystems, it's almost certainly done in >>>> userspace >>>> (except dev scan and technically fi show). >>> >>> >>> Then btrfs check is a userspace-only matter, as it wants the fs >>> unmounted, and it is irrelevant that I did btrfs check from a rescue >>> system with an older kernel, 3.16 if I recall correctly. >> >> >> Not recommended to use older kernel to RW mount or use older fsck to do >> repair. >> As it's possible that older kernel/btrfsck may allocate extent that cross >> the 64K boundary. >> >>> >>>> 2. Regarding general support: If you're using an enterprise distribution >>>> (RHEL, SLES, CentOS, OEL, or something similar), you are almost certainly >>>> going to get better support from your vendor than from the mailing list >>>> or >>>> IRC. >>> >>> >>> My "productive" desktops (fan is one of them) run Debian unstable with >>> a current vanilla kernel. At the moment, I can't use 4.5 because it >>> acts up with KVM. When I need a rescue system, I use grml, which >>> unfortunately hasn't released since November 2014 and is still with >>> kernel 3.16 >> >> >> To fix your problem(make these error message just disappear, even they are >> harmless on recent kernels), the most easy one, is to balance your metadata. > > I did a balance with filter -musage=100 (kernel/tools 4.5/4.5) of the > filesystem mentioned in here: > http://www.spinics.net/lists/linux-btrfs/msg51405.html > > but still bad metadata [ ), crossing stripe boundary messages, > double amount compared to 2 months ago Would you please give an example of the output? So I can check if it's really crossing the boundary. Thanks, Qu > > Kernel operating this fs has always been maximum 1 month behind > 'Latest Stable Kernel' (kernel.org terminology) > >> As I explained, the bug only lies in metadata, and balance will allocate new >> tree blocks, then copy old data into new locations. >> >> In the allocation process of recent kernel, it will avoid such cross >> boundary, and to fix your problem. >> >> But if you are using old kernels, don't scrub your metadata. >> >> Thanks, >> Qu >>> >>> >>> Greetings >>> Marc >>> >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >