All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs send reproducibly fails for a specific subvolume after sending 15 GiB, scrub reports no errors
Date: Thu, 26 Nov 2015 15:44:59 +0000 (UTC)	[thread overview]
Message-ID: <pan$b4680$c7011382$e419cda7$b7453e07@cox.net> (raw)
In-Reply-To: 20151124212746.GS24333@carfax.org.uk

Hugo Mills posted on Tue, 24 Nov 2015 21:27:46 +0000 as excerpted:

[In the context of btrfs send...]

>    -p only sends the file metadata for the changes from the reference
> snapshot to the sent snapshot. -c sends all the file metadata, but will
> preserve the reflinks between the sent snapshot and the (one or more)
> reference snapshots. You can only use one -p (because there's only one
> difference you can compute at any one time), but you can use as many -c
> as you like (because you can share extents with any number of subvols).
> 
>    In both cases, the reference snapshot(s) must exist on the
> receiving side.
> 
>    In implementation terms, on the receiver, -p takes a (writable)
> snapshot of the reference subvol, and modifies it according to the
> stream data. -c makes a new empty subvol, and populates it from scratch,
> using the reflink ioctl to use data which is known to exist in the
> reference subvols.

Thanks, Hugo.  I had a vague idea that the above was the difference in 
general, but as CAM says, the manpage (and wiki) isn't particularly 
detailed on the differences, so I didn't know whether my vague idea was 
correct or not.  Your explanation makes perfect sense and clears things 
up dramatically. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  parent reply	other threads:[~2015-11-26 15:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-22 21:59 btrfs send reproducibly fails for a specific subvolume after sending 15 GiB, scrub reports no errors Nils Steinger
2015-11-23  5:49 ` Duncan
2015-11-23 12:26 ` Austin S Hemmelgarn
2015-11-23 21:10   ` Nils Steinger
2015-11-24  5:42     ` Duncan
2015-11-24 12:46       ` Austin S Hemmelgarn
2015-11-24 18:48         ` Christoph Anton Mitterer
2015-11-24 20:44           ` Austin S Hemmelgarn
2015-11-24 20:50             ` Christoph Anton Mitterer
2015-11-24 20:58               ` Austin S Hemmelgarn
2015-11-24 21:17                 ` Christoph Anton Mitterer
2015-11-24 21:27                   ` Hugo Mills
2015-11-24 21:36                     ` Christoph Anton Mitterer
2015-11-24 22:08                       ` Hugo Mills
2015-11-26 15:44                     ` Duncan [this message]
2015-11-24 21:11 ` Filipe Manana

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='pan$b4680$c7011382$e419cda7$b7453e07@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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 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.