On Wed, Jun 17, 2015 at 10:58:05AM -0700, Marc MERLIN wrote:
> You requested strace -T in the past. I'm showing an exerpt of system calls
> that take
> more than 1 second.
>
> When I see this, I get worried:
> truncate("/mnt/btrfs_pool2/backup/debian64/legolas/varchange_ggm_daily_ro.20150616_23:0
On Wed, May 13, 2015 at 12:35:20PM +0100, Filipe David Manana wrote:
> > 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
On Sun, Sep 14, 2014 at 05:18:36PM -0700, Marc MERLIN wrote:
> I'm still waiting for the next incremental backup to run.
> Once it's done, I'll try to run a smaller one under strace so I don't
> have a ridiculously long log to give you.
>
> Is there a reasonable way to know if btrfs receive is ind
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
On Mon, Sep 8, 2014 at 2:51 AM, Marc MERLIN wrote:
> Hi Filipe and others,
>
> TL;DR:
> - btrfs send of a 1.5GB filesystem takes 4mn to replicate that
> filesystem on the target machine.
> - btrfs send -p between 2 snapshots happens in 1 second
> - copying that diff to the other machine takes 8
Hi Filipe and others,
TL;DR:
- btrfs send of a 1.5GB filesystem takes 4mn to replicate that
filesystem on the target machine.
- btrfs send -p between 2 snapshots happens in 1 second
- copying that diff to the other machine takes 8 seconds
- applying that diff with btrfs receive takes 82mn (again
