From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:30959 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752012AbbC3VVP (ORCPT ); Mon, 30 Mar 2015 17:21:15 -0400 Date: Mon, 30 Mar 2015 17:21:07 -0400 From: Chris Mason Subject: Re: WARNING at fs/btrfs/super.c:260 __btrfs_abort_transaction (error -17) To: Sophie Dexter CC: Message-ID: <1427750467.17204.1@mail.thefacebook.com> In-Reply-To: References: <1427218499.30561.0@mail.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Mon, Mar 30, 2015 at 10:05 AM, Sophie Dexter wrote: >> On 24/03/15 17:34, Chris Mason wrote: >>> You have great timing, there are two reports of a very similar abort >>> with 4.0-rc5, but your report makes it clear these are not a >>> regression >>> from 4.0-rc4. >>> >>> Are you able to run btrfsck on this filesystem? I'd like to check >>> for >>> metadata inconsistencies. >>> >>> -chris >>> >> Hi Chris, >> >> Haha, great timing is the secret of good comedy lol >> >> OpenWrt has only very recently signed off the 3.18 kernel as the >> default >> kernel for my router, I was using a build with 3.14 when I converted >> my >> disk and saw the same problem :!: I may have posted something I >> haven't >> repeated here in the OpenWrt ticket I opened: >> >> https://dev.openwrt.org/ticket/19216 >> >> I previously checked and scrubbed the disk when the problem first >> occurred and happily no problems were found then. Although, I had to >> use >> another computer because btrfs check doesn't complete on my router, >> the >> process is killed due to lack of memory (btrfs invoked oom-killer) >> :-( >> Should I start another topic for this or just accept that that >> problem >> is due to a lack of memory? >> >> I have just run btrfs check again using (yet another) laptop and I >> think >> everything is still OK: >> >> # btrfs check /dev/sdb1 >> Checking filesystem on /dev/sdb1 >> UUID: ########-####-####-####-############ >> checking extents >> checking free space cache >> checking fs roots >> checking csums >> checking root refs >> found 930516788539 bytes used err is 0 >> total csum bytes: 1234353920 >> total tree bytes: 1458515968 >> total fs tree bytes: 54571008 >> total extent tree bytes: 66936832 >> btree space waste bytes: 73372568 >> file data blocks allocated: 1264250781696 >> referenced 1264250781696 >> Btrfs v3.14.1 >> # uname -a >> Linux ######-########-#### 3.16.0-31-generic #43-Ubuntu SMP Tue Mar >> 10 >> 17:37:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> >> Kind regards, >> Sophie x >> >> > I want to continue to use BTRFS as far as possible and have moved > this disk to a Raspberry Pi now because of the problems I encountered > with it when it was plugged into my router. I'd rather do this than > convert back to ext3/4. I'm using Open Media Vault on my Paspberry Pi > and, fingers crossed, haven't had any problems over the weekend. > > I can only guess, given it's inability to complete a btrfs check, > that a router doesn't have enough memory for BTRFS. I'm happy to move > my disk back to my router to try things out and help develop BTRFS > for small computers, but for now at least it has a new home. I have an image that can reproduce this bug, and I'm trying to figure out where we've gone wrong. Hopefully end of day tomorrow I'll have more ideas, but its a run time error related to extent management. Since the FS check is clean, the FS itself isn't corrupt. -chris