From: Martin Steigerwald <martin@lichtvoll.de>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: still kworker at 100% cpu in all of device size allocated with chunks situations with write load
Date: Mon, 14 Dec 2015 09:59:09 +0100 [thread overview]
Message-ID: <36270119.ZeTm4UPz2S@merkaba> (raw)
In-Reply-To: <566E827A.2020604@cn.fujitsu.com>
Hi Qu.
I reply to the journal fs things in a mail with a different subject.
Am Montag, 14. Dezember 2015, 16:48:58 CET schrieb Qu Wenruo:
> Martin Steigerwald wrote on 2015/12/14 09:18 +0100:
> > Am Montag, 14. Dezember 2015, 10:08:16 CET schrieb Qu Wenruo:
> >> Martin Steigerwald wrote on 2015/12/13 23:35 +0100:
[…]
> >> GlobalReserve is just a reserved space *INSIDE* metadata for some corner
> >> case. So its profile is always single.
> >>
> >> The real problem is, how we represent it in btrfs-progs.
> >>
> >> If it output like below, I think you won't complain about it more:
> >> > merkaba:~> btrfs fi df /
> >> > Data, RAID1: total=27.98GiB, used=24.07GiB
> >> > System, RAID1: total=19.00MiB, used=16.00KiB
> >> > Metadata, RAID1: total=2.00GiB, used=728.80MiB
> >>
> >> Or
> >>
> >> > merkaba:~> btrfs fi df /
> >> > Data, RAID1: total=27.98GiB, used=24.07GiB
> >> > System, RAID1: total=19.00MiB, used=16.00KiB
> >> > Metadata, RAID1: total=2.00GiB, used=(536.80 + 192.00)MiB
> >> >
> >> > \ GlobalReserve: total=192.00MiB, used=0.00B
> >
> > Oh, the global reserve is *inside* the existing metadata chunks? Thats
> > interesting. I didn´t know that.
>
> And I have already submit btrfs-progs patch to change the default output
> of 'fi df'.
>
> Hopes to solve the problem.
Nice. Thank you. It clarifies it quite a bit. I always wondered why its
single. On which device does it allocate it in a RAID 1? Also can the data
stored in there temporarily be recreated in case of loosing a device? In case
that not, BTRFS would not guarantee that one device of a RAID 1 can fail at
all times.
Ciao,
--
Martin
next prev parent reply other threads:[~2015-12-14 8:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-13 22:35 Still not production ready Martin Steigerwald
2015-12-13 23:19 ` Marc MERLIN
2015-12-14 7:59 ` still kworker at 100% cpu in all of device size allocated with chunks situations with write load (was: Re: Still not production ready) Martin Steigerwald
2015-12-14 2:08 ` Still not production ready Qu Wenruo
2015-12-14 6:21 ` Duncan
2015-12-14 7:32 ` Qu Wenruo
2015-12-14 12:10 ` Duncan
2015-12-14 19:08 ` Chris Murphy
2015-12-14 20:33 ` Austin S. Hemmelgarn
2015-12-14 8:18 ` still kworker at 100% cpu in all of device size allocated with chunks situations with write load (was: Re: Still not production ready) Martin Steigerwald
2015-12-14 8:48 ` still kworker at 100% cpu in all of device size allocated with chunks situations with write load Qu Wenruo
2015-12-14 8:59 ` Martin Steigerwald [this message]
2015-12-14 9:10 ` safety of journal based fs (was: Re: still kworker at 100% cpu…) Martin Steigerwald
2015-12-22 2:34 ` Kai Krakow
2015-12-15 21:59 ` Still not production ready Chris Mason
2015-12-15 23:16 ` Martin Steigerwald
2015-12-16 1:20 ` Qu Wenruo
2015-12-16 1:53 ` Liu Bo
2015-12-16 2:19 ` Qu Wenruo
2015-12-16 2:30 ` Liu Bo
2015-12-16 14:27 ` Chris Mason
2016-01-01 10:44 ` still kworker at 100% cpu in all of device size allocated with chunks situations with write load Martin Steigerwald
2016-03-20 11:24 ` kworker threads may be working saner now instead of using 100% of a CPU core for minutes (Re: Still not production ready) Martin Steigerwald
2016-09-07 9:53 ` Christian Rohmann
2016-09-07 14:28 ` Martin Steigerwald
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=36270119.ZeTm4UPz2S@merkaba \
--to=martin@lichtvoll.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.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;
as well as URLs for NNTP newsgroup(s).