Partition is larger than filesystem; issue resizing filesystem

John Nomikos · 21 Dec 2022, 19:43

Good afternoon,

On two of the VOXLs we have, the amount of space partitioned for /dev/sda9 is 23.9G.

However, the filesystem only has 15G available. I am not sure why the filesystem is so much smaller than the partition.

voxl:/$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda       8:0    0 24.2G  0 disk 
|-sda1    8:1    0    8K  0 part 
|-sda2    8:2    0   32M  0 part /persist
|-sda3    8:3    0  256M  0 part /cache
|-sda4    8:4    0    1M  0 part 
|-sda5    8:5    0  512K  0 part 
|-sda6    8:6    0  128K  0 part 
|-sda7    8:7    0  128K  0 part 
|-sda8    8:8    0  512K  0 part 
`-sda9    8:9    0 23.9G  0 part /data
sdb       8:16   0    4M  0 disk 
`-sdb1    8:17   0    4M  0 part 
sdc       8:32   0    4M  0 disk 
`-sdc1    8:33   0    4M  0 part 
sdd       8:48   0  128M  0 disk 
|-sdd1    8:49   0   32K  0 part 
|-sdd2    8:50   0    4K  0 part 
`-sdd3    8:51   0    1M  0 part 
sde       8:64   0    4G  0 disk 
|-sde1    8:65   0  512K  0 part 
|-sde2    8:66   0  512K  0 part 
|-sde3    8:67   0    2M  0 part 
|-sde4    8:68   0    2M  0 part 
|-sde5    8:69   0  512K  0 part 
|-sde6    8:70   0  512K  0 part 
|-sde7    8:71   0    2M  0 part 
|-sde8    8:72   0   16K  0 part 
|-sde9    8:73   0  512K  0 part 
|-sde10   8:74   0  512K  0 part 
|-sde11   8:75   0   95M  0 part /firmware
|-sde12   8:76   0   16M  0 part /dsp
|-sde13   8:77   0    1M  0 part 
|-sde14   8:78   0   32M  0 part 
|-sde15   8:79   0    1M  0 part 
|-sde16 259:0    0    1M  0 part 
|-sde17 259:1    0   64M  0 part 
|-sde18 259:2    0    3G  0 part /
|-sde19 259:3    0   64M  0 part 
|-sde20 259:4    0  150M  0 part 
|-sde21 259:5    0    4K  0 part 
|-sde22 259:6    0    1M  0 part 
|-sde23 259:7    0  512K  0 part 
|-sde24 259:8    0  512K  0 part 
|-sde25 259:9    0  256K  0 part 
|-sde26 259:10   0  256K  0 part 
|-sde27 259:11   0  512K  0 part 
|-sde28 259:12   0  512K  0 part 
|-sde29 259:13   0  256K  0 part 
|-sde30 259:14   0  256K  0 part 
|-sde31 259:15   0    4K  0 part 
|-sde32 259:16   0 32.7M  0 part 
`-sde33 259:17   0    2M  0 part 
sdf       8:80   0  1.5G  0 disk 
|-sdf1    8:81   0    2M  0 part 
|-sdf2    8:82   0    2M  0 part 
`-sdf3    8:83   0    4K  0 part 
voxl:/$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       2.8G  1.9G  892M  68% /
devtmpfs        1.8G     0  1.8G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G   17M  1.9G   1% /run
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
tmpfs           1.9G  4.0K  1.9G   1% /var/volatile
/dev/sda2       2.2M   80K  2.0M   4% /persist
/dev/sde11       95M   33M   63M  35% /firmware
/dev/sda3        58M   40K   57M   1% /cache
/dev/sde12       12M  4.1M  7.4M  36% /dsp
/dev/sda9        15G  744M   15G   5% /data

After doing some research, I know entering the command sudo resize2fs /dev/sda9 should resize the filesystem to be as large as the partition. But, when I enter this command, I get a very strange error.

voxl:/$ sudo resize2fs /dev/sda9
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/sda9 is mounted on /data; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
resize2fs: Invalid argument While checking for on-line resizing support
voxl:/$ sudo resize2fs /dev/sda9
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/sda9 is mounted on /data; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
Performing an on-line resize of /dev/sda9 to 6261171 (4k) blocks.
resize2fs: Invalid argument While trying to add group #125

The only info I could find about the same issue is here, and it's not really helpful: https://debian-bugs-dist.debian.narkive.com/ysLUbdet/bug-805716-resize2fs-invalid-argument-while-checking-for-on-line-resizing-support

On another drone we have, the difference in filesystem size to partition size is much greater. They only have 4.6 G of space on /dev/sda9 while the partition of sda9 is 24 G.

Any insights would be appreciated. Thank you.

Chad Sweet · 22 Dec 2022, 18:01

We will have to look into this, we don't have any good answer