From: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
To: "Ellis H. Wilson III" <ellisw@panasas.com>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs-cleaner / snapshot performance analysis
Date: Fri, 9 Feb 2018 21:36:08 +0100 [thread overview]
Message-ID: <96cd9e57-cde4-5bc4-0312-02b54668e59a@mendix.com> (raw)
In-Reply-To: <346220b8-d129-1de9-eb28-6344ec0b0d3a@panasas.com>
On 02/09/2018 05:45 PM, Ellis H. Wilson III wrote:
>
> I am trying to better understand how the cleaner kthread (btrfs-cleaner)
> impacts foreground performance, specifically during snapshot deletion.
> My experience so far has been that it can be dramatically disruptive to
> foreground I/O.
>
> Looking through the wiki at kernel.org I have not yet stumbled onto any
> analysis that would shed light on this specific problem. I have found
> numerous complaints about btrfs-cleaner online, especially relating to
> quotas being enabled. This has proven thus far less than helpful, as
> the response tends to be "use less snapshots," or "disable quotas," both
> of which strike me as intellectually unsatisfying answers
Well, sometimes those answers help. :) "Oh, yes, I disabled qgroups, I
didn't even realize I had those, and now the problem is gone."
>, especially
> the former in a filesystem where snapshots are supposed to be
> "first-class citizens."
Throwing complaints around is also not helpful.
> The 2007 and 2013 Rodeh papers don't do the thorough practical snapshot
> performance analysis I would expect to see given the assertions in the
> latter that "BTRFS...supports efficient snapshots..." The former is
> sufficiently pre-BTRFS that while it does performance analysis of btree
> clones, it's unclear (to me at least) if the results can be
> forward-propagated in some way to real-world performance expectations
> for BTRFS snapshot creation/deletion/modification.
I don't really think they can.
> Has this analysis been performed somewhere else and I'm just missing it?
> Also, I'll be glad to comment on my specific setup, kernel version,
> etc, and discuss pragmatic work-arounds, but I'd like to better
> understand the high-level performance implications first.
The "performance implications" are highly dependent on your specific
setup, kernel version, etc, so it really makes sense to share:
* kernel version
* mount options (from /proc/mounts|grep btrfs)
* is it ssd? hdd? iscsi lun?
* how big is the FS
* how many subvolumes/snapshots? (how many snapshots per subvolume)
And what's essential to look at is what your computer is doing while you
are throwing a list of subvolumes into the cleaner.
* is it using 100% cpu?
* is it showing 100% disk read I/O utilization?
* is it showing 100% disk write I/O utilization? (is it writing lots and
lots of data to disk?)
Since you could be looking at any combination of answers on all those
things, there's not much specific to tell.
--
Hans van Kranenburg
next prev parent reply other threads:[~2018-02-09 20:36 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-09 16:45 btrfs-cleaner / snapshot performance analysis Ellis H. Wilson III
2018-02-09 17:10 ` Peter Grandi
2018-02-09 20:36 ` Hans van Kranenburg [this message]
2018-02-10 18:29 ` Ellis H. Wilson III
2018-02-10 22:05 ` Tomasz Pala
2018-02-11 15:59 ` Ellis H. Wilson III
2018-02-11 18:24 ` Hans van Kranenburg
2018-02-12 15:37 ` Ellis H. Wilson III
2018-02-12 16:02 ` Austin S. Hemmelgarn
2018-02-12 16:39 ` Ellis H. Wilson III
2018-02-12 18:07 ` Austin S. Hemmelgarn
2018-02-13 13:34 ` E V
2018-02-11 1:02 ` Hans van Kranenburg
2018-02-11 9:31 ` Andrei Borzenkov
2018-02-11 17:25 ` Adam Borowski
2018-02-11 16:15 ` Ellis H. Wilson III
2018-02-11 18:03 ` Hans van Kranenburg
2018-02-12 14:45 ` Ellis H. Wilson III
2018-02-12 17:09 ` Hans van Kranenburg
2018-02-12 17:38 ` Ellis H. Wilson III
2018-02-11 6:40 ` Qu Wenruo
2018-02-14 1:14 ` Darrick J. Wong
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=96cd9e57-cde4-5bc4-0312-02b54668e59a@mendix.com \
--to=hans.van.kranenburg@mendix.com \
--cc=ellisw@panasas.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).