How can I interrupt a GParted move filesystem operation and recover the data?

Question

I tried to use GParted to shrink a partition. Apparently, this was a huge mistake because it somehow decided shrink and then move. It took an hour to shrink and it estimates it will take 9 hours to move, what I assume is a handful of megabytes*, to the right.

The data is not extremely critical, but I know enough to know that I know very little about filesystems. I naively assume that because it's "just moving to the right" I may corrupt the file that is in the location that GParted is moving, but I don't think I would corrupt the entire filesystem. Well, perhaps it would corrupt the entire filesystem but I assume it's recoverable?

However this answer said "Just a note: Do NOT interrupt GParted! Doing so will most likely corrupt your partition table or other important disk parts." which made me weary. Perhaps moving filesystems is not a simple "take the bits from over there and put them here" that moves from one end of the memory to the other bit-by-bit.

The answer to the question will likely be useless to me, as I have decided against cancelling the operation. GParted's message "Stopping now will destroy the filesystem, interrupt again if you are sures [sic]" made sure of that.

But I am curious what I can/should do in the future if I am faced with this problem again. If I ever see that GParted wants to do two things, I'll guesstimate when I can get there to force quit between two operations (and, I believe this is possible, double check what GParted wants to do before actually asking GParted to do it...). Because clicking cancel a split second after I saw "Move to the right and shrink it" failed to cancel anything.

I think I will use parted in the future, as I have used it once before and it was one of the most user-friendly command-line applications I've come accross. Because apparently in parted you CAN cancel pending operations without cancelling the currently running operation, whereas this is not implemented in GParted. At least not the version packaged with Rescuezilla.

TL;DR: I don't want to wait for GParted to move the file system. How can I interrupt GParted and recover the most data? Please do not answer "use <file recovery software>".

* this sentence might be confusing. I am moving 1+TiB of data, I'm not super surprised that it is taking so long. When I say handful of megabytes I mean this is how far I believe GParted is actually moving the data.

Answer 1

I tried to use GParted to shrink a partition. Apparently, this was a huge mistake because it somehow decided shrink and then move. It took an hour to shrink and it estimates it will take 9 hours to move, what I assume is a handful of megabytes*, to the right.

Filesystems track all data and metadata positions using offsets from the beginning of the partition, so resize tools are usually written to always shrink from the end (that way they only relocate data that's currently within the range to be chopped, everything else is untouched), and don't support shrinking from the start.

The data is not extremely critical, but I know enough to know that I know very little about filesystems. I naively assume that because it's "just moving to the right" I may corrupt the file that is in the location that GParted is moving, but I don't think I would corrupt the entire filesystem.

In this stage it's moving not individual files, but the whole filesystem as a huge data block. Kind of like this:

During the move that GParted performs, the filesystem itself is "unaware" that the move is happening: its metadata is not updated whenever parts of files are relocated (because the move process doesn't even care that it's moving a filesystem, and because at the very end, when the "start" position is finally moved, all those metadata updates would have to be undone anyway).

So if you interrupt the move mid-way, you will have a situation where all files (and metadata) that are located in the "already moved" part (orange) are now actually stored at an offset from where the filesystem thinks they're stored. (For example, if the move was +1 GB, then a file extent previously located at 100~101 GB is now at 101~102 GB, but the filesystem doesn't know that.)

Well, perhaps it would corrupt the entire filesystem but I assume it's recoverable?

Practically, it's only recoverable if you continue the move process from the same position as it was interrupted. (Some tools can do that, but GParted cannot.)

TL;DR: I don't want to wait for GParted to move the file system. How can I interrupt GParted and recover the most data?

If you knew the exact position where the move was interrupted, it would be in theory recoverable by setting up Device Mapper "dm-linear" to combine the two split halves into one virtual device that works just like the original partition. (I think that's how LVM2 implements pvmove under the hood.) Then the filesystem could be mounted and all data copied out of it.

Alternatively, a tool could be used to move the chunk back to its original location, leaving you where you started. (I don't know if one exists, but it wouldn't take long to write.)

If the split position isn't known, it's pretty much not recoverable. (Well, it might be possible to guess it, as the "gap" still contains the old copy of data that was just "moved out", but I wouldn't bet on it.)

Answer 2

My advice would be NOT to interrupt GParted - there are too many sob stories to be found of people who did cancel it, intentionally or not.

Let it run its course, unless you have a backup image of the disk that you can use to return it to its state as before you started GParted.

Having good backup and not minding the lose of the disk, is the only safe way of stopping GParted, but even then is not worth the bother, as restoring the disk will take as much time as waiting for GParted.

Next time, maybe use another partition editor which is more interruptible.

Answer 3

GParted's GUI cancel button has rollback function built in.

It'll cancel the partition move, then reverse what it has done.

I cancelled a shrink-and-move 30 minutes in out of 8 (1.5 TB of data), took 30 minutes to undo (as expected), and then did only a move that took about 3 hours and now works perfectly.