1

Topic: Resizing Ext4 failed at 20% of copying file.

Dear users,

In my attempt to create an extra partition i moved my 1.3TB partition (of wich 1.29 filled) to the right and shrinked it to make room for an ubuntu install on the left.

I resized the storage partition and then moved it to the right to create a partition on the left.

After checking the harddrive Gparted began copying the files, 18 hours in the proces of this Gparted gave the following message:

"Unnamed Error" and asked me to save the data-log, i did, but Gparted didn't and there was no log to be found.

My gparted was at 20% of copying all the files. But i have no idea how to restore my partition and move it back or complete the move manually.

I am using a 1.5TB Samsung Ecogreen F2 and  the latest version of Gparted Live USB

Can anyone help? I'm rather stuck here, big fan of gParted but this has me stunt.

Regards,
Wouter

2

Re: Resizing Ext4 failed at 20% of copying file.

Hello Wouter.

In my attempt to create an extra partition i moved my 1.3TB partition (of wich 1.29 filled) to the right and shrinked it to make room for an ubuntu install on the left.

I'm affraid that the operating conditions were extreme.
A big hard drive, a big partition almost full, moving with shink to the right, all this makes the operation quite risky.

From my experience, filesystems behave sometimes very strangely when they go almost full. I don't know if this is true for ext4, but it is true for many other filesystems, so it is probable that it happens to ext4 too.
In this case, 1.30-1.29=0.01TB free, that's 0.77%, not even 1%.

A 1.5TB hard drive is in fact 1.36TiB (1.5 trillion bytes).
Do you mean 1.3TB or 1.3TiB partition? (operating systems usually display sizes in binary form: TiB, GiB, MiB). If so, you had to shrink the entire system just 0.06TiB to the right, to create some unallocated space at the drive's head. Was it really necessary? I think it would be much easier to just shrink the partition without moving it. So, you could create new partitions at the end of the drive. I think Ubuntu could install and run at that place, too.

There are many reasons for a resizing/moving process to fail. Hardware and cable problems, power problems, filesystem structure, software bugs. Tha's why we always recommend to backup the drive content before any modifying operation. I know, it is very long (I had myself to repartition a 750GB external USB hard drive, almost full, and spent some days to copy the content elsewere, just to be sure). Partitioning operations are always potentially dangerous.

The log file with GParted details is stored in RAM. We have to mount a device to copy it (any floppy disk, USB flash stick, external or even internal hard drive). By powering down or rebooting the computer, the RAM content is reset and the html file disappears. There is related info at the Documentation page.
GParted details give useful information that often helps to understand what happened.
In general, a stopped resizing or moving operation can be harmful, because it leaves the filesystem to an indeterminate state.

I would recommand 'testdisk', a software that is able to analyse and in many cases fix some problems.
It comes together with 'photorec', a special software for file recovery.

There is a "check filesystem" command in GParted, but I'm not sure if it is able to fix the partition problem or make things worse. (in fact, in such cases it is possible that GParted doesn't detect the damaged partition).

*** It is highly recommended to backup any important files before doing resize/move operations. ***