Btrfs devel - Jun 2012 - Recovering a file from a snapshot without duplicating its blocks (--reflink across devs?)

I hit a problem on my laptop, I had about 40GB free, and I screwed up a
36GB virtualbox image.
No biggie, I have netapp style snapshots, so I deleted my messed up VM
image, and figured I only had to copy the last image from my hourly
snapshot.

First I though, I sure would be nice if I could take btrfs to reference
the same blocks from the snapshot to my current image.
But, --reflink failed across devices nodes, so I was forced to
copy/duplicate the blocks (36GB).

Then, by getting down to less than 10GB free, I got into the dark
corners of the btrfs code where writes would just hang, or take 10H to
copy an extra 1GB, while copiously hanging the system.

In the end, I never was able to recover the system without copying the
snapshot VM image to 3rd party storage, deleting the snapshot, then
getting enough blocks of free space, and finally being able to copy my
36GB image back on my /home partition.

This was very slow and painful and required power cycle my laptop more
than once while it was very close to being fully hung (in real life, it
was just unusable and stuck on disk IO but not fully hung).
Was there a better way?

I had 3.2.16 at the time and now have 3.4.0.

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" -
A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 05/06/12 13:01, Marc MERLIN wrote:
> First I though, I sure would be nice if I could take btrfs to reference
> the same blocks from the snapshot to my current image.
> But, --reflink failed across devices nodes, so I was forced to
> copy/duplicate the blocks (36GB).
Patches for this were posted over a year ago, but it was NAK''d by
Christoph Hellwig.  I don''t know if it''s got any further since
then. :-(

Patch description:

 http://www.spinics.net/lists/linux-btrfs/msg09226.html

NAK:

 http://www.spinics.net/lists/linux-btrfs/msg09229.html

-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Jun 05, 2012 at 01:42:50PM +1000, Chris Samuel
wrote:
> On 05/06/12 13:01, Marc MERLIN wrote:
> 
> > First I though, I sure would be nice if I could take btrfs to
reference
> > the same blocks from the snapshot to my current image.
> > But, --reflink failed across devices nodes, so I was forced to
> > copy/duplicate the blocks (36GB).
> 
> Patches for this were posted over a year ago, but it was NAK''d by
> Christoph Hellwig.  I don''t know if it''s got any further
since then. :-(
> 
> Patch description:
> 
>  http://www.spinics.net/lists/linux-btrfs/msg09226.html
> 
> NAK:
> 
>  http://www.spinics.net/lists/linux-btrfs/msg09229.html
Thanks for that.

So, I''m not sure how common my use case is, but obviously for cases
were
recovering a huge file is important, like disk images, being able to
re-link blocks without copying would be fantastic.

So here''s my vote for that.

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" -
A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html