From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:47766 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751413AbbCaICH (ORCPT ); Tue, 31 Mar 2015 04:02:07 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ycr7T-0007RD-WF for linux-btrfs@vger.kernel.org; Tue, 31 Mar 2015 10:01:56 +0200 Received: from eseye.plus.com ([80.229.36.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Mar 2015 10:01:55 +0200 Received: from Just4pLeisure by eseye.plus.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Mar 2015 10:01:55 +0200 To: linux-btrfs@vger.kernel.org From: Sophie Dexter Subject: Re: WARNING at fs/btrfs/super.c:260 __btrfs_abort_transaction (error -17) Date: Tue, 31 Mar 2015 09:01:14 +0100 Message-ID: References: <1427218499.30561.0@mail.thefacebook.com> <1427750467.17204.1@mail.thefacebook.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed In-Reply-To: <1427750467.17204.1@mail.thefacebook.com> Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 30/03/2015 22:21, Chris Mason wrote: > > > 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 > Hi Chris, That sounds promising. I'll try my disk on my router again when you have something you want to test on a wider audience. Sophie x