From: Josef Bacik <jbacik@fusionio.com>
To: "Ondřej Kunc" <kunc88@gmail.com>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: Btrfs lockup during defrag and removing device
Date: Mon, 24 Jun 2013 11:25:47 -0400 [thread overview]
Message-ID: <20130624152547.GH4288@localhost.localdomain> (raw)
In-Reply-To: <CAOEw3RbTrQkogo44sxdo62+Y8yJd_Bp_QTPQWW7-FVcv4TrJ6w@mail.gmail.com>
On Mon, Jun 24, 2013 at 12:25:07PM +0200, Ondřej Kunc wrote:
> Hi developers,
>
> I have been playing with btrfs on our test server. I have streessed it
> much ... and I can say ... it's troughput and features are very nice
> and usable, but I experienced one problem during testing, btrfs
> triggered lockup of 3 of 8 CPU cores of testing server.
>
> What I was doing ?
>
> Simultaneously:
> - copying 130GB file on one subvolume to another file and measuring speed by pv
> - removing one device (/dev/md3) from btrfs
> - running btrfs defrag on whole fs (via xargs)
> - rsyncing files from another server to subvolume
> - untaring the first 130GB tar to one subdirectory
>
> Our server is HP-DL380, 12*146GB SAS HDD, 72GB RAM, Intel Xeon 5620
> Running uptodate debian wheezy with kernel and btrfs-tools from testing
> 3.9-1-amd64 #1 SMP Debian 3.9.6-1 x86_64 GNU/Linux
> # btrfs version
> Btrfs Btrfs v0.19
>
> btrfs was created on top on 3 software RAID6 devices, every one built
> from 4 SAS drive
>
> About one hour after this(see dmesg) server became inaccessible, so I
> had to restart it by power cycle.
>
> After reboot there was problem with free space cache, but it was fixed
> automatically. I have one suspection, I have tried next this:
>
> btrfs balance start /btrfs
> and then btrfs resize 4:max /btrfs (device was previosly smaller)
>
> it failed with dmesg output: btrfs: dev
> add/delete/balance/replace/resize operation in progress.
>
> So it is possible, that it is mutualy exclusive and should not be
> permitted in the other way, to start balance or defrag when device is
> being removed, is this true ?
>
> Thank you all for your good work!
>
> Ondrej Kunc
>
> dmesg output: http://pastebin.com/Ndxypkxa
>
So it seems like you hit some bug higher up that just made the system devolve
into this chain of panics. I think you are probably hitting this
https://bugzilla.kernel.org/show_bug.cgi?id=59451
which the strato guys are working on. If you take the "btrfs defrag" step out
of that test do you still have the same problem? If yes then it may be
something new and could you file a new bugzilla if thats the case? If it
doesn't reproduce with taking out the defrag step then just attach yourself to
that bugzilla with a "me too" so you can test whatever patch we come up with.
Thanks,
Josef
next prev parent reply other threads:[~2013-06-24 15:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-24 10:25 Btrfs lockup during defrag and removing device Ondřej Kunc
2013-06-24 15:25 ` Josef Bacik [this message]
2013-06-26 11:02 ` Ondřej Kunc
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=20130624152547.GH4288@localhost.localdomain \
--to=jbacik@fusionio.com \
--cc=kunc88@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