I have used gparted quite a few times just to create new partitions on empty drives but on a few occasions I have started to use gparted to shrink an exiting partition to allow me enough space to create a new partition in the unused space of the disk - specifically this time I wanted to shrink an existing partition down to about 3.3TB and use the unused space of about 3.8TB for the new partition. I made the mistake again of thinking that shrinking a partition should be quick . . more than a day later gparted was still “moving blocks” . .
I don’t understand this - why is it necessary to move ANY blocks . . I can see that if I was moving 3.3TB from one place on the drive to another new or overlapping place that that would need to take some time - but why does shrinking and making available UNUSED space take so much time?
When we think of using data in a partition we naturally think of it a “filling up” from the start of the partition to the end. While it is likely true that for a fairly empty partition there may be a higher concentration of used blocks near the beginning of the partition, in reality there are used blocks scattered throughout the whole space. A partition needs to be a series of consecutive blocks, so any used blocks out past where the new “end-point” of the partition will be need to be relocated to an earlier part of the partition prior to shrinking it.
I’m speculating a bit on this part, but I would guess that it really helps control file fragmentation if the filesystem spreads out the initial allocations. This would necessarily scatter sets of blocks across the whole partition. That way changing one or two blocks of a file is still able to keep the data all very localized. When everything is packed tight, which would be necessary to keep everything at the front, then changing a block on an existing file would mean writing that block off away from where the rest of the file is located.
None of that makes your shrink go faster, but maybe it can help explain why the moving is necessary in the first place.
Thanks for the response - I appreciate it! You may be right but my recollection (from a couple of decades ago - so things may bave changed) was that OSs didn’t care about that sort of stuff and just filled up the disk from the inside tracks out. Fragmentation occurred as files got deleted but that was it. When you look at the visual display of GParted it certainly supports that idea but how realistic that representation is I have no idea . .
FYI, I gave up on GParted and found a web page which described a procedure for enlarging a partition using just CLI Parted (with a comment that shrinking would be much the same) and I went through that exercise but it was quite unsuccessful . . if your description is accurate, it would explain why . .
The disk, if it’s a spinning disk, will be made up of several platters, and a corresponding number of heads. As data writing occurs on several platters for the particular file, thereby making read and write access faster physically. A consequence is when you add data (files) or remove it, you change the blocks and available space across all platters and heads, this can result in fragmentation increasing, and usually does. When you go to do shrinking, I would think running fsck would be a must first, or if on btrfs btrfs-balance or something like. Just some thoughts on it.