Can't shrink an ext4 partition (is bigalloc at play here?)

[BrunoMiranda]

Hi all,
I'm trying to shrink a ext4 partition but I'm being unable at it. I've googled around and found no way to solve this, so here's my request for help.
This partition is on a 2nd spinning HDD I have for multimedia, so no system files here. Swapping is also off.
No, it's not mounted while I try to resize it. I always remember this metaphor: "You can't pick a carpet up to dust it off while you're standing on it!".
It's partitioned with the old ms-dos partition type, not GPT.
I'm on Mint 20.3 and the partition was created with it. I've tried with a Mint 21 live USB (including to give you the gparted printscreen in English since my OS is in Portuguese) and the results are the very same.

What I think it might be: Since I mostly keep videos here, I've formatted it with 512K cluster size, and that implies bigalloc. I think that's eventually what's keeping me from resizing.

So what I've noticed:
- Gparted shows no free space when the drive is dismounted. When it is mounted, it shows its free space. Also minimum space and maximum space are equal. Gparted gives me no ability to slide the thingy to manage my free space and the new partition size as it should be. (printscreen below)

https://imgur.com/OxMStz0

- The disk utility (gnome-disks) allows me to slide and select a new size within its possible range but when I click OK I get an error (printscreen below) stating that the new size is smaller than the minimum. I have 42GB free and I've failed trying to create room for a new partition from 10 to 42GB. I just need 10GB for this new partition.

https://imgur.com/tLWW5bB


Output from dumpe2fs -h /dev/sdb1:

Code: Select all

sudo dumpe2fs -h /dev/sdb1
dumpe2fs 1.45.5 (07-Jan-2020)
Filesystem volume name:   Documentos
Last mounted on:          /media/Documentos
Filesystem UUID:          98a503f8-dc86-4f64-943a-133713c63a0f
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize bigalloc metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              100080
Block count:              37499648
Reserved block count:     0
Free blocks:              11321856
Free inodes:              99091
First block:              0
Block size:               4096
Cluster size:             524288
Group descriptor size:    64
Reserved GDT blocks:      15
Blocks per group:         4194304
Clusters per group:       32768
Inodes per group:         11120
Inode blocks per group:   695
Flex block group size:    16
Filesystem created:       Tue May  3 21:17:16 2022
Last mount time:          Fri Oct  7 04:29:24 2022
Last write time:          Fri Oct  7 04:29:24 2022
Mount count:              1
Maximum mount count:      -1
Last checked:             Fri Oct  7 04:28:29 2022
Check interval:           0 (<none>)
Lifetime writes:          642 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      69668ddc-9a3e-40f4-aa3f-e3f80d8de363
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x1cd24a1c
Journal features:         journal_incompat_revoke journal_64bit journal_checksum_v3
Journal size:             1024M
Journal length:           262144
Journal sequence:         0x000e6ef6
Journal start:            1
Journal checksum type:    crc32c
Journal checksum:         0xee7e3984

So is there any practical way to shrink this partition?

Would formatting it with GPT solve this issue?

Should I stop formatting partitions (where I store large files) with a different cluster size than default so it doesn't require bigallog? (bigalloc's ext4.wiki.kernel.org page info is from 2013, I'm sure it's more stable now than it was back then, or am I wrong?)

I have the spare room on another HDD to backup all the data and swipe this one clear if needed but that would be a time consuming solution. If formatting it with GPT would solve this, sure, but if I would have to move all the data to another disk, clean the disk, create a new partition the size I need and move all the data back each time I might need to readjust partition sizes, it just would not be practical at all...

Any hints?
As always, thanks guys!

[Hoser Rob]

... Should I stop formatting partitions (where I store large files) with a different cluster size than default so it doesn't require bigallog? (bigalloc's ext4.wiki.kernel.org page info is from 2013, I'm sure it's more stable now than it was back then, or am I wrong?)....

YES.

[JerryF]

From what GParted shows, the disk partition is full.

[BrunoMiranda]

... Should I stop formatting partitions (where I store large files) with a different cluster size than default so it doesn't require bigallog? (bigalloc's ext4.wiki.kernel.org page info is from 2013, I'm sure it's more stable now than it was back then, or am I wrong?)....

YES.

Could you please kindly clarify?
I regard using bigalloc as safe, in these few years I've never had data loss. But that's just my own personal anecdotal experience.
All the data I find about it is old, I assume it as safe.
I use it so I can have a bigger cluster size and maximize disk storage for large files, mainly video.
So what am I missing here?

[BrunoMiranda]

From what GParted shows, the disk partition is full.

Yes but that is with the partition unmounted. When it is mounted it shows its has (40GB+) free space. Printscreen:

https://imgur.com/PYJCeRG

Usually Gparted allows me to slide down that available space into a new empty space in order to create a new partition. And if it has to, Gparted will automatically move files so it consolidates that free space and tidy up the room for free contiguous space.
But that's not happening here. And of course it doesn't allow me to shrink the drive while mounted.

[JerryF]

From what GParted shows, the disk partition is full.

Yes but that is with the partition unmounted. When it is mounted it shows its has (40GB+) free space.
...

GParted should show the size of the partition, used space, and unused space whether it is mounted or unmounted. I've never seen what your pic shows.

Are you using some kind of encryption or compression on it?

Can you post the results of the following command:

Code: Select all

sudo parted --list

[BrunoMiranda]

From what GParted shows, the disk partition is full.

Yes but that is with the partition unmounted. When it is mounted it shows its has (40GB+) free space.
...

GParted should show the size of the partition, used space, and unused space whether it is mounted or unmounted. I've never seen what your pic shows.

Are you using some kind of encryption or compression on it?

Can you post the results of the following command:

Code: Select all

sudo parted --list

Information regarding this disk:
(Note: Since I have my OS in Portuguese, I've roughly translated the text so you can have an idea)

Code: Select all

sudo parted --list
Model: ATA Hitachi HTS54321 (scsi)
Disk /dev/sdb: 160GB
Sector size (logical / physical): 512B/512B
Partition Table: msdos
Disk signalers:

Number    Start      End      Size       Type       File system      Signalizers
 1            1049kB   154GB   154GB    primary  ext4
 2            154GB    160GB   6441MB  primary  linux-swap(v1)

No, no compression or encryption at play here.

[senjoz]

Gparted shows no free space when the drive is dismounted. When it is mounted, it shows its free space.

GParted should show the size of the partition, used space, and unused space whether it is mounted or unmounted. I've never seen what your pic shows.

Maybe this can explain the difference.

[BrunoMiranda]

I've got a brand new blank SSD (this is the reason for all this partition ruffle) and I've been playing with it trying to replicate this.

What I have found:
- Using GPT instead of msdos for the partition table does not change things.
- On one test Gparted reported a hint: according to resize2fs 1.45.5 (07-Jan-2020) [on Mint 20.3): Resizing bigalloc filesystems is not completely tested. Proceed at your own risk! Use the Force option if you pretend to proceed anyway.
- I go to the terminal and try to force it with the -M option (to shrink the partition as much as it can) and resize2fs reports, on 2 different bigalloc partitions, that The filesystem has already x (4K) blocks. Nothing to do! when there are tens of free GB available.

So with this I conclude that, according to resize2fs 1.45.5 (07-Jan-2020) [recent enough] resizing bigalloc filesystems is not a clear cut yet. This means it is not practical for everyday use where one might need to resize it to get free space in order to install some OS (my actual case and need here!) or do something else that involves partition resizing.

I've got all my data backed up and I'm ready to nuke and pave that hard drive if needed and start over with GPT and stop using bigalloc. That would solve this issue permanently.
But I'm leaving this untouched yet for some more days and using this case as a learning experience for me and for us all, in case some valuable help might arrive. So, with all data backed up and no fear of data loss, if you have any ideas, bring it on!!

[BrunoMiranda]

Gparted shows no free space when the drive is dismounted. When it is mounted, it shows its free space.

GParted should show the size of the partition, used space, and unused space whether it is mounted or unmounted. I've never seen what your pic shows.

Maybe this can explain the difference.

Yes, that explanation goes along with my practical experience. Thanks!