linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
To: Ivan P <chrnosphered@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs-tools/linux 4.11: btrfs-cleaner misbehaving
Date: Sat, 27 May 2017 21:33:58 +0200	[thread overview]
Message-ID: <c3d2a91c-6fea-d273-2d58-1f8ea700b942@mendix.com> (raw)
In-Reply-To: <CADzmB23Ytbp4eQcXZstFNM9W76Ug6DuyK-4rm_-VgOKzLsw1mQ@mail.gmail.com>

Hi,

On 05/27/2017 08:53 PM, Ivan P wrote:
> 
> for a while now, btrfs-cleaner has been molesting my system's btrfs partition,
> as well as my CPU. The behavior is as following:
> 
> After booting, nothing relevant is happening. After about 5-30 minutes,
> a btrfs-cleaner process is spawned, which is constantly using one CPU core.
> The btrfs-cleaner process never seems to finish (I've let it waste CPU cycles
> for 9 hours) and also cannot be stopped or killed.
> 
> Rebooting again usually resolves the issue for some time.
> But on next boot, the issue usually reappears.
> 
> I'm running linux 4.11.2, but the issue is also present on current LTS 4.9.29.
> I am using newest btrfs-tools, as far as I can tell (4.11). The system is an
> arch linux x64 installed on a Transcend 120GB mSATA drive.
> 
> No other disks are present, but the root volume contains several subvolumes
> (@arch<date> snapshots, @home, @data).
> 
> The logs don't contain anything related to btrfs, beside the usual diag output
> on mounting the root partition.
> 
> I am mounting the btrfs partition with the following options:
> 
> subvol=@arch_current,compress=lzo,ssd,noatime,autodefrag
> 
> What information should I provide so we could debug this?

What I usually do first in a similar situation is look at the output of

  watch cat /proc/<pid>/stack

where <pid> is the pid of the btrfs-cleaner thread.

This might already give an idea what kind of things it's doing, by
looking at the stack trace. When it's cleaning up a removed subvolume
for example, there will be a similar function name in the stack somewhere.

-- 
Hans van Kranenburg

  reply	other threads:[~2017-05-27 19:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-27 18:53 btrfs-tools/linux 4.11: btrfs-cleaner misbehaving Ivan P
2017-05-27 19:33 ` Hans van Kranenburg [this message]
2017-05-27 20:29   ` Ivan P
2017-05-27 20:42     ` Hans van Kranenburg
2017-05-27 20:54       ` Ivan P
2017-05-28  4:55         ` Duncan
2017-05-28  7:13           ` Marat Khalili
2017-05-27 19:36 ` Jean-Denis Girard
     [not found] <20170527215608.23a40176@ws>
2017-05-28 10:39 ` Ivan P

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=c3d2a91c-6fea-d273-2d58-1f8ea700b942@mendix.com \
    --to=hans.van.kranenburg@mendix.com \
    --cc=chrnosphered@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;
as well as URLs for NNTP newsgroup(s).