Re: WARNING at fs/btrfs/super.c:260 __btrfs_abort_transaction (error -17)

[Sophie Dexter <Just4pLeisure@gmail.com>]

On 30/03/2015 22:21, Chris Mason wrote:
>
>
> 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
>
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