From: Peter Volkov <pva@gentoo.org>
To: Robert White <rwhite@pobox.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs stuck with lot's of files
Date: Tue, 02 Dec 2014 04:50:29 +0300 [thread overview]
Message-ID: <1417485029.4310.22.camel@gentoo.org> (raw)
In-Reply-To: <547CB7D0.4040800@pobox.com>
В Пн, 01/12/2014 в 10:47 -0800, Robert White пишет:
> On 12/01/2014 03:46 AM, Peter Volkov wrote:
> > (stuff about getting hung up trying to write to one drive)
>
> That drive (/dev/sdn) is probably starting to fail.
> (about failed drive)
Thank you Robert for the answer. It is not likely that drive fails here.
Similar condition (write to a single drive) happens with other drives
i.e. such write pattern may happen with any drive.
After looking at what happens longer I see the following. During stuck
single processor core is busy 100% of CPU in kernel space (some kworker
is taking 100% CPU). Ftrace reveals that
btrfs_async_reclaim_metadata_space is most frequently called function.
So it looks like btrfs is doing some operation with metadata and until
it finishes that everything is stuck (practically no writes happens on
disk). So I'm looking for suggestion on how to cope with this process.
> > # btrfs filesystem df /store/
> > Data, single: total=11.92TiB, used=10.86TiB
>
> Reguardless of the above...
>
> You have a terabyte of unused but allocated data storage. You probably
> need to balance your system to un-jamb that. That's a lot of space that
> is unavailable to the metadata (etc).
Well, I'm afraid that balance will put fs into even longer "stuck".
> ASIDE: Having your metadata set to RAID1 (as opposed to the default of
> DUP) seems a little iffy since your data is still set to DUP.
That's true. But why data is duplicated? During btrfs volume creation
I've set explicitly -d data single.
> FUTHER ASIDE: raid1 metadata and raid5 data might be good for you given
> 22 volumes and 10% empty empty space it would only cost you half of your
> existing empty space. If you don't RAID your data, there is no real
> point to putting your metadata in RAID.
Is raid5 ready for use? As I read post[1] mentioned on[2] it is still
some way to make it stable.
[1]
http://marc.merlins.org/perso/btrfs/post_2014-03-23_Btrfs-Raid5-Status.html
[2] https://btrfs.wiki.kernel.org/index.php/RAID56
--
Peter.
next prev parent reply other threads:[~2014-12-02 1:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-01 11:46 btrfs stuck with lot's of files Peter Volkov
2014-12-01 18:47 ` Robert White
2014-12-02 1:50 ` Peter Volkov [this message]
2014-12-02 12:48 ` Duncan
2014-12-02 18:56 ` Ian Armstrong
2014-12-02 22:42 ` Duncan
2014-12-02 1:33 ` Qu Wenruo
2014-12-02 2:00 ` Peter Volkov
2014-12-04 22:58 ` Reiterate: " Peter Volkov
2014-12-04 23:55 ` Chris Murphy
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=1417485029.4310.22.camel@gentoo.org \
--to=pva@gentoo.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=rwhite@pobox.com \
/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