Why is GParted moving free space?

Question

I have a 4 TB drive with 2 partitions - a 1TB partition (halfway used) and a 3TB partition (not even 300GB had been used).

I took the files from the 1TB partition and put it in the 3TB one in preparation for moving it. (In hindsight it may have been better to move the data to the 1TB partition since it was on the left of the drive.)

I go into GParted and delete the empty 1TB partition and resize the 3TB to fill the drive.

For over 12 hours GParted has been moving what is essentially more than 2TB of free space to the left of my drive and I have no clue as to why it would need to move this free space.

Can someone explain why it needs to do this?

As a side note the filesystem is NTFS so maybe that provides a better explanation?

Answer 1

According to this post, asking a somewhat related question (about shrinking a partition to move it more quickly) on the GParted forums, GParted doesn't support NTFS as natively (and thus, as efficiently) as many filesystems that are designed for use in linux. So your side note that NTFS is the filesystem you're waiting on, is likely key to your answer.

Also important to note, with disk fragmentation and similar issues, the "Empty Space", is likely not as perfectly homogenous at the beginning of the disk as it appears in the preview, and GParted doesn't want to risk corrupting your data if it's not handled perfectly, or is a bit messy in filling up the partition.

The problem with this is that it requires the file system to be in a definitiely clean state - otherwise, the resize operations (especially shrinking) would destroy data. While this is relatively easy to ensure for the typical Linux file systems (GParted brings the tools required to check and fix them with it on the Live media), it is not so easy for third-parts file systems like NTFS: For these file systems, you often need to boot the "native" operating system for these file systems and perform some magic there. In addition to this, even some of the Linux file systems can not be moved this way, since there is no known way to shrink them (jfs / XFS / Reiser4) - and to enlarge them, they need to be mounted, and growing must be done on-line (jfs / XFS). Depending on your machine, this is not a very clever idea - maybe you perform the resize operations on a system with very little RAM (and modern file systems can consume huge amounts of memory).