Re: Connection lost during BTRFS move + resize

Even if it wrote more than 1 TB and started overwriting the file
system, it SHOULD be possible to find what data still needs to be
written by searching backwards from the old partition's end point and
the new partition's end point until you start finding identical data.

Matthew Warren

On Mon, Nov 29, 2021 at 5:07 PM Graham Cobb [off-list ref] wrote:

On 29/11/2021 15:50, Borden wrote:

quoted

29 Nov 2021, 10:26 by phill@thesusis.net:

quoted

The only tool I know of that can do this is gparted, so I assume you are
using that.  In this case, it has to umount the filesystem and manually
copy data from the old start of the partition to the new start.  Being
interrupted in the middle leaves part of the filesystem in the wrong
place ( and which parts is unknowable ), and so it is toast.  This is
one area where LVM has a significant advantage as its moves are
interruption safe and automatically resumed on the next activation of
the volume.

This is the answer that I anticipated, and it's good to know now so I don't destroy data that I _cannot_ afford to lose later. So thank you.

For my own education/curiosity/intellectual banter: ddrescue, badblocks, rsync and other utilities have log files that track progress and allow it to resume if it's interrupted. Since resize operations work in the linear process you described, how hard would it be, theoretically, to implement a "needle position" in a move operation to allow a move to pick up where it left off?

Obviously, it wouldn't be 100% perfect, but if a recovery utility could look at the disk and say "partition starts here, skip a bit somewhere in the middle, continue here, stop there," surely that would be more efficient than trying to recover files with a low-level utility?

I can't comment on that, and I don't know how the utility you were using
works, but if it was copying blocks from higher disk addresses to lower
ones, starting at the bottom, it is *possible* that it hadn't got beyond
the first 1TB before it failed and the original filesystem is still
untouched.

Did you try just resetting the original partition parameters manually
(forcing them using something like GNU parted's mkpart - not a resize
operation) to see whether the original filesystem could be mounted? It's
just a long shot, of course.

Graham