On Mon, Mar 30, 2015 at 10:05 AM, Sophie Dexter
<Just4pLeisure@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
