Re: Kernel bug during RAID1 replace

[Saint Germain <saintger@gmail.com>]

On Wed, 29 Jun 2016 18:24:07 -0600, Chris Murphy
<lists@colorremedies.com> wrote :

> On Wed, Jun 29, 2016 at 5:51 PM, Saint Germain <saintger@gmail.com>
> wrote:
> > On Wed, 29 Jun 2016 19:23:57 +0000, Hugo Mills <hugo@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
> >> > <lists@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.