All of lore.kernel.org
 help / color / mirror / Atom feed
From: Filipe David Manana <fdmanana@gmail.com>
To: Marc MERLIN <marc@merlins.org>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	Filipe David Borba Manana <fdmanana@suse.com>
Subject: Re: btrfs differential receive has become excrutiatingly slow on one machine
Date: Wed, 13 May 2015 12:35:20 +0100	[thread overview]
Message-ID: <CAL3q7H7SYfka5MK=8XZkw1m7PGjyR-1fzrD0tP_=dhznQ5QdGQ@mail.gmail.com> (raw)
In-Reply-To: <20150511214412.GE15670@merlins.org>

On Mon, May 11, 2015 at 10:44 PM, Marc MERLIN <marc@merlins.org> wrote:
> On Sun, Sep 14, 2014 at 05:18:36PM -0700, Marc MERLIN wrote:
>> On Mon, Sep 08, 2014 at 10:49:01PM +0100, Filipe David Manana wrote:
>> > Hi Marc,
>> >
>> > Does the sum of all reads from the stream file (fd 3) gets anywhere
>> > close to the total btrfs receive time? (or even more than 50%)
>> > Can you paste somewhere the full output of strace (with -T option)?
>>
>> Sorry for the lack of answer, I lost the snapshot I used for that mail,
>> so it was not possible to do again easily.
>> Because my backups were so hopelessly behind, I did a full resync of
>> /var, i.e. not a differential send (300GB or so). The copy went at about
>> 25GB/h, which wasn't bad at all since was over wifi (took about 14H).
>
> Sigh, now that I'm resyncing my laptop I just rebuilt after the btrfs
> crash, to my server (both running 3.19.5+), full btrfs sends (i.e. not
> incremental), are taking ages.
>
> I'm seeing less than 100GB/day on my home network when my tcp
> connections over wifi easily get 50MB/s
>
> Right now I'm seeing the equivalent of aout 1MB/s, or 50 times less than
> what my network connection can do.
>
> Last time I tried to strace btrfs send, it killed the process with
> SIGPIPE and I lost a full day of sync and had to start over :(
>
> It's a broad question, but how can I diagnose btrfs send being so slow
> without taking the risk of killing my connection?
> (if there is no good answer on this one, I can try another sync later
> with -vvv and strace if you'd like)

Try to see if it's a problem at the sending side or at the receiving
side. Redirect send's output to a file, see how much it takes. Then
run receive with that file as input and see how long it takes.
You can also use 'perf record -ag' while doing both, it might give
some useful information.

>
> Thanks,
> Marc
> --
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems ....
>                                       .... what McDonalds is to gourmet cooking
> Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901



-- 
Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."

  reply	other threads:[~2015-05-13 11:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-08  1:51 btrfs differential receive has become excrutiatingly slow on one machine Marc MERLIN
2014-09-08 21:49 ` Filipe David Manana
2014-09-15  0:18   ` Marc MERLIN
2014-09-15 17:57     ` Marc MERLIN
2014-09-16 23:57       ` btrfs differential receive has become excrutiatingly slow with COW files Marc MERLIN
2014-09-17 15:00         ` NOCOW on VM images causes extreme btrfs slowdowns, memory leaks, and deadlocks Marc MERLIN
2014-09-17 17:13           ` Marc MERLIN
2015-05-11 21:44     ` btrfs differential receive has become excrutiatingly slow on one machine Marc MERLIN
2015-05-13 11:35       ` Filipe David Manana [this message]
2015-06-17 17:58         ` Marc MERLIN
2015-06-17 21:54           ` Marc MERLIN

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='CAL3q7H7SYfka5MK=8XZkw1m7PGjyR-1fzrD0tP_=dhznQ5QdGQ@mail.gmail.com' \
    --to=fdmanana@gmail.com \
    --cc=fdmanana@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=marc@merlins.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 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.