On Wed, Jun 29, 2016 at 09:16:13PM +0200, Saint Germain wrote: > On Wed, 29 Jun 2016 13:08:30 -0600, Chris Murphy > <li...@colorremedies.com> wrote : > > > >> > Ok I will follow your advice and start over with a fresh BTRFS > > >> > volume. As explained on another email, rsync doesn't support > > >> > reflink, so do you think it is worth trying with BTRFS send > > >> > instead ? Is it safe to copy this way or rsync is more reliable > > >> > in case of faulty BTRFS volume ? > > >> > > > >> If you have the space, btrfs restore would probably be the best > > >> option. It's not likely, but using send has a risk of contaminating > > >> the new filesystem as well. > > >> > > > > > > I have to copy through the network (I am running out of disks...) so > > > btrfs restore is unfortunately not an option. > > > I didn't know that btrfs send could contaminate the target disk as > > > well ? > > > Ok rsync it is then. > > > > restore will let you extract files despite csum errors. I don't think > > send will, and using cp or rsync Btrfs definitely won't hand over the > > file. > > > > That's Ok I'd prefer to avoid copying files with csum errors anyway (I > can restore them from backups). > However will btrfs send abort the whole operation as soon as it finds a > csum error ? > And will I have the risk to "contaminate" the target BTRFS volume by > using BTRFS send ?
A send stream is effectively just a sequence of filesystem commands (mv, cp, cp --reflink, rm, dd). So any damage that it can do when replayed by receive is limited to what you can do with the basic shell commands (plus cloning extents). If you have metadata breakage in your source filesystem, this won't cause the same metadata breakage to show up in the target filesystem. Hugo. -- Hugo Mills | Quidquid latine dictum sit, altum videtur hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 |
signature.asc
Description: Digital signature
