1 Topic by hongo (edited by hongo 2011-05-16 18:13:30)

  • hongo
  • New member
  • Offline
  • Registered: 2011-04-19
  • Posts: 5

Topic: [SOLVED] move and grow interruption

I have a 1TB external HD. I had a 20 GB NTFS partition and a 910 GB ext4 partition in that order. I was trying to increase the NTFS partition to 40 GB and reduce the ext4 accordingly. When I tried to do this a 1 MB empty space appears between them so I move to the left the ext4 and grow it accordingly. The were 3 operations to be done
1) Move to the right and shrink from 910 to 890 GB the ext4 partition (/dev/sdb2)
2) Grow the ntfs from 20 to 40 GB (/dev/sdb1)
3) Move the ext4 to the left and grow it to use all the unallocated space (/dev/sdb2)

While doing step 3 gparted was interrupted and now I cannot access the ext4 partition. I created an image of the disk and tried to fix the ext4 partition using e2fsck and I could recover only 3 folders but I couldn't recover the rest of my important information. I know I should have made a back up but now it's too late. I was studying a little bit about ext filesystem and playing with lde and now I can understand it better, I can even change some things just by hex editing the partition manually. What I need to know is how gparted do the moving and growing process. I need to know the exact steps describing what happens with the inodes, the inodes table, the block size, the superblocks, etc so I can try to figure out how to recover my info, if the inode information was deleted or if it is still there somewhere. Does gparted uses internally resize2fs to move and grow a partition? Should I ask this in a resize2fs forum if so?
Any gparted developer or anyone how may have the answer to my question?
I was thinking that maybe the inodes have all the information but there are pointing to incorrect blocks but I don't know enough about what gparted or resizefs does during the moving and resizing operation so I don't have any clue.

2 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,593

Re: [SOLVED] move and grow interruption

GParted uses resize2fs to grow or shrink an ext4 partition.

GParted performs a sector by sector copy to move or copy a partition.

3 Reply by hongo

  • hongo
  • New member
  • Offline
  • Registered: 2011-04-19
  • Posts: 5

Re: [SOLVED] move and grow interruption

I am almost sure that the process was interrupted while in step 3 gparted was copying sector by sector. So if I can find the spot where gparted was interrupted and copy sector by sector back to the original stage my partition will be restored back?
At this stage was the new partition size and location written to disk or not? where is this information? in the master boot record?

4 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,593

Re: [SOLVED] move and grow interruption

With a move operation, the partition is first enlarged to fit encompass the entire space needed by both the original and the new location partition.  Then it is copied sector by sector to the new location.  If all goes well then the partition set to the new location.

If you need more detail than that, then please feel free to look at the source code.  The file that contains this code is GParted_Core.cc.

5 Reply by hongo

  • hongo
  • New member
  • Offline
  • Registered: 2011-04-19
  • Posts: 5

Re: [SOLVED] move and grow interruption

I don't think I will understand but I will try.
When you say sector by sector ... this is starting from the inodes, superblock, inode table, etc?
So I just need to find where the process was stopped and continuing copying sector by sector and I will fix the problem. do you think?

6 Reply by gedakc (edited by gedakc 2011-04-20 19:20:53)

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,593

Re: [SOLVED] move and grow interruption

When the copy process stopped, GParted would have noted the sector where the copy stopped.  If you did not save the gparted_details.htm log file, or write this information down, then it is very difficult and laborious to determine at which sector the copy process failed.

When copying ext4 partitions, GParted does not look at any of the the file system information such as inodes.  Instead it performs a block by block copy which copies empty sectors as well as sectors containing information.

EDIT:
You may wish to look at the source code above to determine if GParted was copying starting from the right, or starting from the left side of the partition.

7 Reply by hongo

  • hongo
  • New member
  • Offline
  • Registered: 2011-04-19
  • Posts: 5

Re: [SOLVED] move and grow interruption

I wish I could have saved the gparted_details.htm, the problem was that my computer ran out of power so there was not chance of saving the details. I wish gparted would write a log file automatically by default, I don't know why it doesn't do that. As you are a developer I would like to suggest you this for the next version of gparted. I am not the first one who needs a gparted log file.
There should be a way to deduce where the process was stopped by looking at the blocks pointed by the inodes and where are the correct blocks for example by looking at inodes that points to the directories inside the root directory. When I do a e2fsck I can recover some of these directories. This is probably because the sectors where these directories are were moved so the rest of them must be moved.

Thank you for your help it was very useful. I will let you know how I solve it if can.

8 Reply by hongo (edited by hongo 2011-05-16 18:04:01)

  • hongo
  • New member
  • Offline
  • Registered: 2011-04-19
  • Posts: 5

Re: [SOLVED] move and grow interruption

Finally, I did it. I recovered all the information without any single block lost.
What I did is
1) first identify the number of bytes I have to move the rest of the filesystem
2) and where I have to continue copying.

To identify (1) what I did is:
-The broken ext4 partition was located at /dev/sdc2
-The block size was of 4096 bytes
# sudo mke2fs -n /dev/sdc2
I've got:
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848
So hexediting the /dev/sdc2 I've found that all the superblock copies were located where they were supposed to be up to the block 23887872
The rest of the suprblock backups where not located at the following expected blocks. So I searched for the rest of the disk for the first 16 bytes of the superblock. I found the positions of rest of the superblock copies, the missing superblock backups.
I subtracted the position where I located the missing superblocks to where they were supposed to be. So the shift was of 4022337536 bytes.
Now with this number I was ready to find where I have to start moving the rest of the system (2). If gparted was just copying byte per byte from right to left where the operation was interrupted there must be at the left an identical zone to the right shifted by this magic number. And the size of this repeated zone has to be greater or equal to the shift size. So I made a program to find this zone just by comparing byte per byte with the next byte to the right shifted by this number. Fortunately I could find this zone and it was exactly equal in size as the shift number. Then I've just copied using dd the right side of the partition to the left by the shifted number staring at the end of the cloned zone.
I could recover my whole 1 TB hard drive thanks to the information you provide me.
I hope this information would be useful for somebody else sometime. If somebody needs the programs I wrote or more details about how I did it, just ask it here.
Thank you!!

9 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,593

Re: [SOLVED] move and grow interruption

Wow, that is great news that you were able to recover your whole partition.   smile

To help other users searching for this type of information, you can edit the initial post to prefix SOLVED in front of the title.

10 Reply by jayseejc

  • jayseejc
  • New member
  • Offline
  • Registered: 2011-05-18
  • Posts: 1

Re: [SOLVED] move and grow interruption

Ok. That's great that you got your 1TB hard drive back!
Just wondering if you could send me more detailed instructions. I was shrinking my ubuntu partition to make room for a 100mb grub legacy partition, and there was 1mb of unused pace at the beginning of the hard drive that I just ignored in the past. Gparted wanted to move my ubuntu partition over that 1mb, for reasons I don't know. Either way, while it was resizing (running off the puppy linux 511 live cd) my computer froze, or at least the GUI did. After about 20min of no response, I decided to gamble and hit the reset button. Upon rebooting, I was brought to the grub2 recovery (although gparted's frozen display said that it was in the read only part of the process) I rebooted again to the puppy live cd. At this point, I cannot mount my ubuntu drive, and Gparted cant do anything to it. All my main personal files are on another hard drive, but I have a slow internet connection at home and really don't want to sith there for hours to reinstall all the stuff I lost on my main install. Please help!
By the way, i know nothing about hex editing at this time, but i am a fast learner.

11 Reply by cross731_1

  • cross731_1
  • New member
  • Offline
  • From: Chicago, IL USA
  • Registered: 2011-09-17
  • Posts: 4

Re: [SOLVED] move and grow interruption

What program did you use to move the sectors? I have a similar problem (http://gparted-forum.surf4.info/viewtopic.php?id=15293). With some help, I learned that I can restore my hard drive by moving the copied sectors to it's old location. I'm currently in search for a program that can move sectors. What would you recommend?

12 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,593

Re: [SOLVED] move and grow interruption

For new problems I suggest opening a new thread.  To copy sectors, the "dd" command is useful.

13 Reply by msdobrescu (edited by msdobrescu 2017-02-13 22:42:10)

  • msdobrescu
  • New member
  • Offline
  • Registered: 2017-02-13
  • Posts: 1

Re: [SOLVED] move and grow interruption

Hi, I know I come many years after te original discussion, but I need to ask: did anybody make a tool out of this solution? Is it possible such thing? Would be wonderful to recover 99% of some partition which faced this kind of problem. I am waiting for a similar operation to finish, it is estimated to take totally 55 hours on a 2.27TB  disk and if I knew it would take this long, I wouldn't have done it from the start. Also, some time estimation would have been useful before starting the operation itself. Should I say what extraordinary thing would have been to leave data in place and redirect the files references only? It's an ext4, BTW.