On Wed, 29 Jun 2016 18:24:07 -0600, Chris Murphy <li...@colorremedies.com> wrote :
> On Wed, Jun 29, 2016 at 5:51 PM, Saint Germain <saint...@gmail.com> > wrote: > > On Wed, 29 Jun 2016 19:23:57 +0000, Hugo Mills <h...@carfax.org.uk> > > wrote : > > > >> 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. > >> > > > > Well after 300GB copied through "btrfs send", the process is aborted > > with the following error: > > ERROR: send ioctl failed with -5: Input/output error > > ERROR: unexpected EOF in stream. > > > > /var/log/syslog relevant lines are appended at the end of this > > email. > > > > So it seems that I will have to go with rsync then. > > You'll likely hit the same bad file and get EIO, is my guess. What you > can do is mount it ro from the get go, and do btrfs send receive again > and maybe then it won't hit this sequence where it's finding some need > to clean up a transaction and free an extent. Maybe you still get some > failure to send whatever file is using that extent, but I think > receive will tolerate it. > Well I tried "btrfs send" and the process stalled at 300 GB (on a total of 2 TB) with a never ending stream of: "ERROR: unexpected EOF in stream." I gave up and launched a rsync which is about to be finished. Now I have some work to make sure that all rsynced files are consistent (I have to compared them to the backuped ones). Thanks for your help, I learned a bit more about BTRFS this way. -- 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
