Partition is larger than filesystem; issue resizing filesystem

John Nomikos

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

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