On Mon, Feb 24, 2020 at 02:53:51PM +0000, Filipe Manana wrote:
> On Tue, Jul 23, 2019 at 12:19 PM Filipe Manana <fdmanana@xxxxxxxxx> wrote:
> >
> > On Tue, Jul 23, 2019 at 3:25 AM Omar Sandoval <osandov@xxxxxxxxxxx> wrote:
> > >
> > > From: Omar Sandoval <osandov@xxxxxx>
> > >
> > > When we process a clone request, we look up the source subvolume by
> > > UUID, even if the source is the subvolume that we're currently
> > > receiving. Usually, this is fine. However, if for some reason we
> > > previously received the same subvolume, then this will use paths
> > > relative to the previously received subvolume instead of the current
> > > one. This is incorrect, since the send stream may use temporary names
> > > for the clone source. This can be reproduced as follows:
> > >
> > > btrfs subvolume create subvol
> > > dd if=/dev/urandom of=subvol/foo bs=1M count=1
> > > cp --reflink subvol/foo subvol/bar
> > > mkdir subvol/dir
> > > mv subvol/foo subvol/dir/
> > > btrfs property set subvol ro true
> > > btrfs send -f send.data subvol
> > > mkdir first second
> > > btrfs receive -f send.data first
> > > btrfs receive -f send.data second
> > >
> > > The second receive results in this error:
> > >
> > > ERROR: cannot open first/subvol/o259-7-0/foo: No such file or directory
> > >
> > > Fix it by always cloning from the current subvolume if its UUID matches.
> > > This has the nice side effect of avoiding unnecessary UUID tree lookups
> > > in that case.
> > >
> > > Fixes: f1c24cd80dfd ("Btrfs-progs: add btrfs send/receive commands")
> > > Signed-off-by: Omar Sandoval <osandov@xxxxxx>
> >
> > Reviewed-by: Filipe Manana <fdmanana@xxxxxxxx>
>
> I can't find this patch in btrfs-progs. Any reason why it was never applied?
>
> thanks
It must have gotten lost at some point. I'll resend it.
