On Wed, Jun 29, 2016 at 1:16 PM, Saint Germain <saint...@gmail.com> 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 ?
By default yes, but it's the receive side that aborts. So you use --max-errors 0 to let it tolerate unlimited errors, and use -v for both send and receive to track what errors there are. > And will I have the risk to "contaminate" the target BTRFS volume by > using BTRFS send ? No. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
