You are not logged in.
Howdy-ha, fellow Archers. So to make room for some new software I'd like to use for a project, I decided to use Gparted to resize my "/" partition (EXT4) on a 40-gig SSD, from ~5.5G to ~8G. during the process, however, I got the following error:
The combination of flex_bg and !resize_inode features is not supported by resize2fs.Afterward, while Gparted shows the intended new size of the partition, both df and cdf display the old stats. Also, despite reading the filesystem as the correct size, the free:used ratio is roughly the same, meaning whatever the case I've gained nothing from the process. Anyone had this experience? My Google-fu only turned up cases in which either an LVM setup suffered this (the disk only has two partitions), or the user attempted a massive resize (only ~2.5G in my case). Please tell me I didn't bork my partition/SSD; the fact that the NTFS partition on the same disk didn't suffer any problems is kind of depressing ![]()
Offline
Try e2fsck? When not just copy data elsewhere, nuke disk, repartition and copy data back? Did this twice in the past few weeks while needing to flash SSD firmware.
Offline
Thanks, graysky. I actually cloned the partition to an external drive and back again a while after posting (without actually knowing if it would work
). I guess I was wondering exactly what happened, and why. If something is technically impossible, why exactly would Gparted try it? What aspect of the filesystem was altered without touching any actual data? It's just a confusing situation, and I wasn't sure if the problem was with Gparted, EXT4, or some quirk of SSDs, or how to find out. I'm not sure if I should mark this as "Solved" without knowing for future reference.
Offline