1 (edited by kwass.hipolit 2020-10-27 21:54:29)

Topic: Unallocated disk space equal exactly to one MiB after shrink/grow

I am using gparted-live-1.1.0-5-amd64.iso on disk with gpt partition table.

Initial state of partition on drive is as follows (start sector, last sector, sector count) - it looks like every partition is MiB aligned at the beginning:

               start sect  last sect    sect cnt
/dev/nvme0n1p1      2048     1026047     1024000
/dev/nvme0n1p2   1026048   123906047   122880000
/dev/nvme0n1p3 123906048   944005119   820099072
/dev/nvme0n1p4 944005120   976773119    32768000

So far I dry tried to perform two operations (with MiB alignment turned on):

  • shrink partition 'p3' by 20000MiB and move its start sector to the right

  • grow partition 'p2' into free space.

I end up with:

/dev/nvme0n1p2   1026048 164863999 163837952          (79999 MiB size)
unallocated    164864000 164866047      2048          (    1 MiB size)
/dev/nvme0n1p3 164866048 944005119 779139072

This leaves exactly 1MiB (2048 sectors * 512 bytes/sector) of unallocated space.

The question is: I cannot understand why gparted insists on having this exactly 1MiB gap and not allowing p2 to grow to 80000 MiB. Now p2 size is 79999MiB.

As far as I understand information from this page https://gparted.org/display-doc.php%3Fn … alignment:

Use MiB alignment for modern operating systems. This setting aligns partitions to start and end on precise mebibyte (1,048,576 byte) boundaries. MiB alignment provides enhanced performance when used with RAID systems and with Solid State Drives, such as USB flash drives.

partition p2 which would look like this (it allocated this free 1 MiB and has size of 80000MiB):

/dev/nvme0n1p2   1026048 164866047 163840000

is perfectly aligned to MiB, so this gap that gparted introduced seems unnecessary.

Is this unallocated space a feature or a bug? Is is safe (from alignment point of view) to disable "MiB alignment" in gparted and manually "force" p2 to grow to 80000MiB?

2

Re: Unallocated disk space equal exactly to one MiB after shrink/grow

Can you queue and apply the resize operation, then save the gparted_details.htm file and post it in this forum?

3

Re: Unallocated disk space equal exactly to one MiB after shrink/grow

Here you are:

GParted 1.1.0

configuration --enable-online-resize

libparted 3.3

========================================
Device:    /dev/nvme0n1
Model:    Samsung SSD 970 EVO 500GB
Serial:    none
Sector size:    512
Total sectors:    976773168
 
Heads:    255
Sectors/track:    2
Cylinders:    1915241
 
Partition table:    gpt
 
Partition    Type    Start    End    Flags    Partition Name    File System    Label    Mount Point
/dev/nvme0n1p1    Primary    2048    1026047    boot, esp    UEFI_BOOT    fat32        
/dev/nvme0n1p2    Primary    1026048    123906047        SYSTEM    ext4        
/dev/nvme0n1p3    Primary    123906048    944005119        HOME    ext4        
/dev/nvme0n1p4    Primary    944005120    976773119    swap    SWAP    linux-swap        

========================================
Device:    /dev/sda
Model:    ATA WDC WD10EZEX-00R
Serial:    WD-WCC1S2767309
Sector size:    512
Total sectors:    1953525168
 
Heads:    255
Sectors/track:    2
Cylinders:    3830441
 
Partition table:    gpt
 
Partition    Type    Start    End    Flags    Partition Name    File System    Label    Mount Point
/dev/sda1    Primary    2048    1953523711        WDC_1T    ext4        

========================================
Device:    /dev/sdb
Model:    Samsung Flash Drive
Serial:    none
Sector size:    512
Total sectors:    125313283
 
Heads:    255
Sectors/track:    2
Cylinders:    245712
 
Partition table:    gpt
 
Partition    Type    Start    End    Flags    Partition Name    File System    Label    Mount Point
/dev/sdb1    Primary    2048    125247713    msftdata    Ventoy    exfat    ventoy    
/dev/sdb2    Primary    125247714    125313249    hidden, msftdata    VTOYEFI    fat16        

========================================
Move /dev/nvme0n1p3 to the right and shrink it from 391.05 GiB to 371.52 GiB  00:01:33    ( SUCCESS )
         
calibrate /dev/nvme0n1p3  00:00:00    ( SUCCESS )
         
path: /dev/nvme0n1p3 (partition)
start: 123906048
end: 944005119
size: 820099072 (391.05 GiB)
check file system on /dev/nvme0n1p3 for errors and (if possible) fix them  00:00:02    ( SUCCESS )
         
e2fsck -f -y -v -C 0 '/dev/nvme0n1p3'  00:00:02    ( SUCCESS )
         
Pass 1: Checking inodes, blocks, and sizes
Inode 14418103 extent tree (at level 1) could be shorter. Optimize? yes

Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/nvme0n1p3: ***** FILE SYSTEM WAS MODIFIED *****

293138 inodes used (1.14%, out of 25632768)
1834 non-contiguous files (0.6%)
182 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 292447/222
6736578 blocks used (6.57%, out of 102512384)
0 bad blocks
2 large files

240077 regular files
52485 directories
0 character device files
0 block device files
4 fifos
26 links
560 symbolic links (454 fast symbolic links)
3 sockets
------------
293155 files
e2fsck 1.45.6 (20-Mar-2020)
shrink file system  00:00:12    ( SUCCESS )
         
resize2fs -p '/dev/nvme0n1p3' 389569536K  00:00:12    ( SUCCESS )
         
Resizing the filesystem on /dev/nvme0n1p3 to 97392384 (4k) blocks.
Begin pass 2 (max = 20266)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 3129)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 54219)
Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/nvme0n1p3 is now 97392384 (4k) blocks long.

resize2fs 1.45.6 (20-Mar-2020)
shrink partition from 391.05 GiB to 371.52 GiB  00:00:00    ( SUCCESS )
         
old start: 123906048
old end: 944005119
old size: 820099072 (391.05 GiB)
new start: 123906048
new end: 903045119
new size: 779139072 (371.52 GiB)
check file system on /dev/nvme0n1p3 for errors and (if possible) fix them  00:00:01    ( SUCCESS )
         
e2fsck -f -y -v -C 0 '/dev/nvme0n1p3'  00:00:01    ( SUCCESS )
         
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

293138 inodes used (1.20%, out of 24354816)
1834 non-contiguous files (0.6%)
182 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 292444/225
6655290 blocks used (6.83%, out of 97392384)
0 bad blocks
2 large files

240077 regular files
52485 directories
0 character device files
0 block device files
4 fifos
26 links
560 symbolic links (454 fast symbolic links)
3 sockets
------------
293155 files
e2fsck 1.45.6 (20-Mar-2020)
grow partition from 371.52 GiB to 391.05 GiB  00:00:00    ( SUCCESS )
         
old start: 123906048
old end: 903045119
old size: 779139072 (371.52 GiB)
new start: 123906048
new end: 944005119
new size: 820099072 (391.05 GiB)
move file system to the right  00:01:17    ( SUCCESS )
         
e2image -ra -p -O 20971520000 '/dev/nvme0n1p3'  00:01:17    ( SUCCESS )
         
e2image 1.45.6 (20-Mar-2020)
Scanning inodes...
Copied 6649388 / 6649388 blocks (100%) in 00:01:11 at 365.83 MB/s s
shrink partition from 391.05 GiB to 371.52 GiB  00:00:01    ( SUCCESS )
         
old start: 123906048
old end: 944005119
old size: 820099072 (391.05 GiB)
new start: 164866048
new end: 944005119
new size: 779139072 (371.52 GiB)

========================================
Grow /dev/nvme0n1p2 from 58.59 GiB to 78.12 GiB  00:00:03    ( SUCCESS )
         
calibrate /dev/nvme0n1p2  00:00:00    ( SUCCESS )
         
path: /dev/nvme0n1p2 (partition)
start: 1026048
end: 123906047
size: 122880000 (58.59 GiB)
check file system on /dev/nvme0n1p2 for errors and (if possible) fix them  00:00:02    ( SUCCESS )
         
e2fsck -f -y -v -C 0 '/dev/nvme0n1p2'  00:00:02    ( SUCCESS )
         
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

540937 inodes used (14.08%, out of 3842048)
2037 non-contiguous files (0.4%)
947 non-contiguous directories (0.2%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 455736/770
11262759 blocks used (73.33%, out of 15360000)
0 bad blocks
2 large files

403420 regular files
50266 directories
221 character device files
75 block device files
1 fifo
29445 links
86889 symbolic links (84070 fast symbolic links)
56 sockets
------------
570373 files
e2fsck 1.45.6 (20-Mar-2020)
grow partition from 58.59 GiB to 78.12 GiB  00:00:00    ( SUCCESS )
         
old start: 1026048
old end: 123906047
old size: 122880000 (58.59 GiB)
new start: 1026048
new end: 164863999
new size: 163837952 (78.12 GiB)
grow file system to fill the partition  00:00:01    ( SUCCESS )
         
resize2fs -p '/dev/nvme0n1p2'  00:00:01    ( SUCCESS )
         
Resizing the filesystem on /dev/nvme0n1p2 to 20479744 (4k) blocks.
Begin pass 1 (max = 156)
Extending the inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/nvme0n1p2 is now 20479744 (4k) blocks long.

resize2fs 1.45.6 (20-Mar-2020)

4

Re: Unallocated disk space equal exactly to one MiB after shrink/grow

Well, what do you know...

After previous step after which p2 remained 79999MiB long, and gparted gui refused to make it 80000MiB, I rebooted to gparted once again, chose to resize p2 to 80000MiB and then it had no troubles to do that.

GParted 1.1.0

configuration --enable-online-resize

libparted 3.3

========================================
Device:    /dev/nvme0n1
Model:    Samsung SSD 970 EVO 500GB
Serial:    none
Sector size:    512
Total sectors:    976773168
 
Heads:    255
Sectors/track:    2
Cylinders:    1915241
 
Partition table:    gpt
 
Partition    Type    Start    End    Flags    Partition Name    File System    Label    Mount Point
/dev/nvme0n1p1    Primary    2048    1026047    boot, esp    UEFI_BOOT    fat32        
/dev/nvme0n1p2    Primary    1026048    164863999        SYSTEM    ext4        
/dev/nvme0n1p3    Primary    164866048    944005119        HOME    ext4        
/dev/nvme0n1p4    Primary    944005120    976773119    swap    SWAP    linux-swap        

========================================
Device:    /dev/sda
Model:    ATA WDC WD10EZEX-00R
Serial:    WD-WCC1S2767309
Sector size:    512
Total sectors:    1953525168
 
Heads:    255
Sectors/track:    2
Cylinders:    3830441
 
Partition table:    gpt
 
Partition    Type    Start    End    Flags    Partition Name    File System    Label    Mount Point
/dev/sda1    Primary    2048    1953523711        WDC_1T    ext4        

========================================
Device:    /dev/sdb
Model:    Samsung Flash Drive
Serial:    none
Sector size:    512
Total sectors:    125313283
 
Heads:    255
Sectors/track:    2
Cylinders:    245712
 
Partition table:    gpt
 
Partition    Type    Start    End    Flags    Partition Name    File System    Label    Mount Point
/dev/sdb1    Primary    2048    125247713    msftdata    Ventoy    exfat    ventoy    
/dev/sdb2    Primary    125247714    125313249    hidden, msftdata    VTOYEFI    fat16        

========================================
Grow /dev/nvme0n1p2 from 78.12 GiB to 78.12 GiB  00:00:02    ( SUCCESS )
         
calibrate /dev/nvme0n1p2  00:00:00    ( SUCCESS )
         
path: /dev/nvme0n1p2 (partition)
start: 1026048
end: 164863999
size: 163837952 (78.12 GiB)
check file system on /dev/nvme0n1p2 for errors and (if possible) fix them  00:00:01    ( SUCCESS )
         
e2fsck -f -y -v -C 0 '/dev/nvme0n1p2'  00:00:01    ( SUCCESS )
         
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

540814 inodes used (10.56%, out of 5120000)
2037 non-contiguous files (0.4%)
947 non-contiguous directories (0.2%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 455615/769
11346206 blocks used (55.40%, out of 20479744)
0 bad blocks
2 large files

403361 regular files
50203 directories
221 character device files
75 block device files
1 fifo
29445 links
86889 symbolic links (84070 fast symbolic links)
55 sockets
------------
570250 files
e2fsck 1.45.6 (20-Mar-2020)
grow partition from 78.12 GiB to 78.12 GiB  00:00:00    ( SUCCESS )
         
old start: 1026048
old end: 164863999
old size: 163837952 (78.12 GiB)
new start: 1026048
new end: 164866047
new size: 163840000 (78.12 GiB)
grow file system to fill the partition  00:00:01    ( SUCCESS )
         
resize2fs -p '/dev/nvme0n1p2'  00:00:01    ( SUCCESS )
         
Resizing the filesystem on /dev/nvme0n1p2 to 20480000 (4k) blocks.
The filesystem on /dev/nvme0n1p2 is now 20480000 (4k) blocks long.

resize2fs 1.45.6 (20-Mar-2020)

5

Re: Unallocated disk space equal exactly to one MiB after shrink/grow

kwass.hipolit wrote:

is perfectly aligned to MiB, so this gap that gparted introduced seems unnecessary.

Is this unallocated space a feature or a bug? Is is safe (from alignment point of view) to disable "MiB alignment" in gparted and manually "force" p2 to grow to 80000MiB?

This is a bug in GParted.  When composing both operations the second grow operation is incorrectly prevented from using the final 1 MiB of available space.

The recommended workaround it to compose and apply one operation at a time, keeping the MiB alignment.

An alternative workaround is to use alignment none for the resize move.  However applying multiple resize/move operations with alignment none may result is the partitions not being aligned to MiB boundaries, so this is not recommended.

6

Re: Unallocated disk space equal exactly to one MiB after shrink/grow

This bug has been logged as GParted issue 113 - GParted forcing 1 MiB gap between 2 adjacent partitions when resizing both together

7

Re: Unallocated disk space equal exactly to one MiB after shrink/grow

All clear, thank you.