linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <clm@fb.com>
To: Sophie Dexter <Just4pLeisure@gmail.com>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: WARNING at fs/btrfs/super.c:260 __btrfs_abort_transaction (error -17)
Date: Mon, 30 Mar 2015 17:21:07 -0400	[thread overview]
Message-ID: <1427750467.17204.1@mail.thefacebook.com> (raw)
In-Reply-To: <mfbl7d$fsr$1@ger.gmane.org>



On Mon, Mar 30, 2015 at 10:05 AM, Sophie Dexter 
<Just4pLeisure@gmail.com> 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




  reply	other threads:[~2015-03-30 21:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-20 15:19 WARNING at fs/btrfs/super.c:260 __btrfs_abort_transaction (error -17) Sophie Dexter
2015-03-24 13:43 ` Sophie Dexter
2015-03-24 17:34   ` Chris Mason
2015-03-24 22:23     ` Sophie
2015-03-30 14:05       ` Sophie Dexter
2015-03-30 21:21         ` Chris Mason [this message]
2015-03-31  8:01           ` Sophie Dexter
2015-04-01 14:13       ` Chris Mason
2015-04-02 12:38         ` Sophie Dexter
2015-04-03 21:42           ` Sophie Dexter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1427750467.17204.1@mail.thefacebook.com \
    --to=clm@fb.com \
    --cc=Just4pLeisure@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).