All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Chris Murphy <lists@colorremedies.com>
Cc: "Jürgen Herrmann" <t-5@t-5.eu>,
	"Btrfs BTRFS" <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs send hangs after partial transfer and blocks all IO
Date: Thu, 13 Sep 2018 18:44:35 +0300	[thread overview]
Message-ID: <5c0b3895-05c8-63b1-195a-316d3eaca072@suse.com> (raw)
In-Reply-To: <CAJCQCtQFfGzNrCSVsZXutfx+O5BdNEELieVuHbJ0mLBqATc-cw@mail.gmail.com>



On 13.09.2018 18:30, Chris Murphy wrote:
> This is the 2nd or 3rd thread containing hanging btrfs send, with
> kernel 4.18.x. The subject of one is "btrfs send hung in pipe_wait"
> and the other I can't find at the moment. In that case though the hang
> is reproducible in 4.14.x and weirdly it only happens when a snapshot
> contains (perhaps many) reflinks. Scrub and check lowmem find nothing
> wrong.
> 
> I have snapshots with a few reflinks (cp --reflink and also
> deduplication), and I see maybe 15-30 second hangs where nothing is
> apparently happening (in top or iotop), but I'm also not seeing any
> blocked tasks or high CPU usage. Perhaps in my case it's just
> recovering quickly.
> 
> Are there any kernel config options in "# Debug Lockups and Hangs"
> that might hint at what's going on? Some of these are enabled in
> Fedora debug kernels, which are built practically daily, e.g. right
> now the latest in the build system is 4.19.0-0.rc3.git2.1 - which
> translates to git 54eda9df17f3.

If it's a lock-related problem then you need Lock Debugging => Lock
debugging: prove locking correctness

> 
> 
> Chris Murphy
> 

  reply	other threads:[~2018-09-13 20:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-13  8:34 btrfs send hangs after partial transfer and blocks all IO Jürgen Herrmann
2018-09-13  8:40 ` Nikolay Borisov
2018-09-13 10:29   ` Jürgen Herrmann
2018-09-13 10:50     ` Nikolay Borisov
2018-09-13 10:56       ` Jürgen Herrmann
2018-09-13 11:04         ` Nikolay Borisov
2018-09-13 11:50           ` Jürgen Herrmann
2018-09-13 12:02             ` Nikolay Borisov
2018-09-13 12:30               ` Jürgen Herrmann
2018-09-13 12:35                 ` Nikolay Borisov
2018-09-13 15:30                   ` Chris Murphy
2018-09-13 15:44                     ` Nikolay Borisov [this message]
2018-09-13 16:22                       ` Chris Murphy
2018-09-19 19:35                         ` Jürgen Herrmann
2018-09-19 19:41                   ` Jürgen Herrmann
2018-09-20 17:25                     ` 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=5c0b3895-05c8-63b1-195a-316d3eaca072@suse.com \
    --to=nborisov@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=t-5@t-5.eu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.