linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bbrendon@gmail.com
To: linux-btrfs@vger.kernel.org
Subject: Re: kernel crash when balancing raid56 after low on space
Date: Sun, 17 Jan 2016 11:54:09 -0800	[thread overview]
Message-ID: <CADrfcdYnCkbdHs9EmmvC3WoRPm_O3WnZRiCwcqKM2X3tFv8V-Q@mail.gmail.com> (raw)
In-Reply-To: <CADrfcdae8Z7towaXpuA=dtq-GP-hMxJZp69UP5TayH20_ZMvBw@mail.gmail.com>

I was able to get this issue resolved.

I think the key to realize is that when mounting with skip_balance,
that doesn't actually disable/cancel the balance. You still have to
run the 'btrfs balance cancel FS' command. Once I did this, I was able
to mount the FS without the crashing. For some reason a balance resume
was casing the crashes.

I then did a balance dusage=5, and then a full balance. The full
balance has been running for a day so I'm guessing it'll finish
successfully in a few more days.

On Thu, Jan 14, 2016 at 11:03 PM,  <bbrendon@gmail.com> wrote:
> Looking for a bit of help getting this FS balanced. I'm getting a
> kernel crash and readonly file system error:
> [ 9357.096562] Workqueue: btrfs-extent-refs btrfs_extent_refs_helper [btrfs]
>
> dmesg output. http://pastebin.com/c9xKvpZ0
>
> This problem began because of performance issues. Basically the FS
> appeared to be hung. (I think because it got to about 100GB free) I
> added a drive and started a rebalance which somehow also hung. I then
> aborted the whole thing, upgraded from 4.3 to 4.4 and after a long
> wait the FS mounted. I deleted more snaps and now when I start a
> balance, the FS goes read-only.
>
> Thanks for any help you can provide! -Brendon
>
> # uname -a
> Linux humvee 4.4.0 #1 SMP Thu Jan 14 15:54:03 PST 2016 x86_64 GNU/Linux
>
> #  btrfs --version
> btrfs-progs v4.3
> #
>
> # btrfs fi show
> Label: 'tank0'  uuid: d25217dd-91f1-4add-8c07-66eacff9fb28
>         Total devices 6 FS bytes used 6.22TiB
>         devid    1 size 3.64TiB used 3.52TiB path /dev/sdc
>         devid    2 size 3.64TiB used 3.52TiB path /dev/sdd
>         devid    3 size 3.64TiB used 3.52TiB path /dev/sde
>         devid    4 size 3.64TiB used 3.52TiB path /dev/sdf
>         devid    5 size 3.64TiB used 3.52TiB path /dev/sdg
>         devid    6 size 3.64TiB used 1.00GiB path /dev/sdh
>
> btrfs-progs v4.3
> #
> #  btrfs fi df /tank0
> Data, RAID6: total=10.55TiB, used=6.21TiB
> System, RAID6: total=96.00MiB, used=880.00KiB
> Metadata, RAID6: total=19.59GiB, used=10.34GiB
> GlobalReserve, single: total=512.00MiB, used=0.00B
> #

      reply	other threads:[~2016-01-17 19:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-15  7:03 kernel crash when balancing raid56 after low on space bbrendon
2016-01-17 19:54 ` bbrendon [this message]

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=CADrfcdYnCkbdHs9EmmvC3WoRPm_O3WnZRiCwcqKM2X3tFv8V-Q@mail.gmail.com \
    --to=bbrendon@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).