From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: Leszek Dubiel <leszek@dubiel.pl>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
Chris Murphy <lists@colorremedies.com>,
Remi Gauvin <remi@georgianit.com>
Subject: Re: very slow "btrfs dev delete" 3x6Tb, 7Tb of data
Date: Sat, 28 Dec 2019 15:23:44 -0500 [thread overview]
Message-ID: <20191228202344.GE13306@hungrycats.org> (raw)
In-Reply-To: <cc364577-1bb8-1512-4d2e-dc7e465ca2d6@dubiel.pl>
[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]
On Sat, Dec 28, 2019 at 06:04:21PM +0100, Leszek Dubiel wrote:
>
> PROBLEM SOLVED --- btrfs was busy cleaing after snaphot deletion few days
> ago, so it dodn't have time to "dev delete", that's why it was slow
That checks out. Snapshot delete and remove-device/resize/balance are
not able to run at the same time. There is a mutex, so one or the
other will run while the other is blocked.
> =======================
>
>
> I restarted server, so job "btrfs delete" was not existent any more.
> But disks were still working (!!!). I wondered why? What is BTRFS doing all
> the time?
>
> I realized that afew days before starting "btrfs dev delete" I have removed
> many snapshots -- there were about 400 snapshots and I left 20 only. I did
> that because I have read that many snapshot could slowdown btrfs operations
> severely.
>
>
>
> I made an experiment on another testing serwer:
>
> 1. started command "watch -n1 'btrfs fi df /"
> 2. started "iostat -x -m"
>
> Disks were not working at all.
>
>
> 3. Then I removed many shapshots on that testing server
>
> and I was watching:
>
> Data, single: total=6.56TiB, used=5.13TiB
> System, RAID1: total=32.00MiB, used=992.00KiB
> Metadata, RAID1: total=92.00GiB, used=70.56GiB
> GlobalReserve, single: total=512.00MiB, used=1.39MiB
>
> Disks started to work hard. So btrfs was probably cleaining after snapshot
> deletion.
>
> At the beginning in "Metadata" line there was "used=70.00GiB".
>
> Metadata, RAID1: total=92.00GiB, used=70.00GiB
>
> It was changing all the time... getting lower and lower. During that process
> in line
>
> GlobalReserve, single: total=512.00MiB, used=1.39MiB
>
> "used=" was going up until it reached about 100MiB, then it was flushed to
> zero, and started again to fill, flush, fill, flush... some
> loop/buffer/cache (?).
> It convinced me, that after snapshot deletion btrfs is really working hard
> on cleanup.
> After some time "Metadata...used=" stopped changing, disks stopped working,
> server got lazy again.
>
>
>
> I got back to main server. Started to watch "Metadata...used=". It was going
> down and down...
> I waited. When "Metadata...used=" stopped changing, then "iostat -m" stopped
> showing any disk activity.
>
> I started "btrfs dev delete" again and now speed is 50Mb/sek. Hurrray!
> Problem solved.
>
>
> Sorry for not beeing clever enough to connect all this facts at the
> beginning.
> Anyway -- maybe in the future someone has the same problem, then btrfs
> experts could ask him if he let btrfs do some other hard work in the same
> time (eg cleaning up after massive snapsot deletion).
>
> Maybe it would be usful to have a tool to ask btrfs "what are you doing? are
> you busy?".
> It would respond "I am cleaing up after snapshot deletion... I am
> balancing... I am scrubbing... I am resizing... I am deleting ...".
Usually 'top' or 'iotop' suffices for that. btrfs-cleaner = deleting
snapshots, other activities will be tied to their respective userspace
agents. The balance/delete/resize/drop-snapshot mutex is the only special
case that I know of where one btrfs maintenance thread waits for another.
It might be handy to give users a clue on snapshot delete, like add
"use btrfs sub list -d to monitor deletion progress, or btrfs sub sync
to wait for deletion to finish".
>
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2019-12-28 20:23 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-25 22:35 very slow "btrfs dev delete" 3x6Tb, 7Tb of data Leszek Dubiel
2019-12-26 5:08 ` Qu Wenruo
2019-12-26 13:17 ` Leszek Dubiel
2019-12-26 13:44 ` Remi Gauvin
2019-12-26 14:05 ` Leszek Dubiel
2019-12-26 14:21 ` Remi Gauvin
2019-12-26 15:42 ` Leszek Dubiel
2019-12-26 22:40 ` Chris Murphy
2019-12-26 22:58 ` Leszek Dubiel
2019-12-28 17:04 ` Leszek Dubiel
2019-12-28 20:23 ` Zygo Blaxell [this message]
2020-01-02 18:37 ` Leszek Dubiel
2020-01-02 21:57 ` Chris Murphy
2020-01-02 22:39 ` Leszek Dubiel
2020-01-02 23:22 ` Chris Murphy
2020-01-03 9:08 ` Leszek Dubiel
2020-01-03 19:15 ` Chris Murphy
2020-01-03 14:39 ` Leszek Dubiel
2020-01-03 19:02 ` Chris Murphy
2020-01-03 20:59 ` Leszek Dubiel
2020-01-04 5:38 ` Zygo Blaxell
2020-01-07 18:44 ` write amplification, was: " Chris Murphy
2020-01-07 19:26 ` Holger Hoffstätte
2020-01-07 23:32 ` Zygo Blaxell
2020-01-07 23:53 ` Chris Murphy
2020-01-08 1:41 ` Zygo Blaxell
2020-01-08 2:54 ` Chris Murphy
2020-01-06 11:14 ` Leszek Dubiel
2020-01-07 0:21 ` Chris Murphy
2020-01-07 7:09 ` Leszek Dubiel
2019-12-26 22:15 ` Chris Murphy
2019-12-26 22:48 ` Leszek Dubiel
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=20191228202344.GE13306@hungrycats.org \
--to=ce3g8jdj@umail.furryterror.org \
--cc=leszek@dubiel.pl \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=remi@georgianit.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