Calculate correctly the ext2 used blocks by the file system

What I'm trying achieve is, a safe shrinking of an ext2 file system and make sure I can cut/shrink the physical partition underneath to a safe minimum (without cutting file system blocks). I have checked many HowTo-s, but still want to ask if I'm missing something, when determining the actual ext2 usage as reported by dumpe2fs. Here is my test case: root@buster:/tmp# dd if=/dev/zero of=/tmp/del.img bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 0.429782 s, 2.4 GB/s root@buster:/tmp# losetup -f --show /tmp/del.img /dev/loop0 root@buster:/tmp# mkfs.ext2 /dev/loop0 mke2fs 1.44.5 (15-Dec-2018) Discarding device blocks: done Creating filesystem with 256000 4k blocks and 64000 inodes Filesystem UUID: 217a401a-a001-46e8-8ca2-9602e927e2aa Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Allocating group tables: done Writing inode tables: done Writing superblocks and filesystem accounting information: done root@buster:/tmp# mount /dev/loop0 /mnt/EXT2/ root@buster:/tmp# dumpe2fs /dev/loop0 | grep -E '(Block count|Block size)' dumpe2fs 1.44.5 (15-Dec-2018) Block count: 256000 Block size: 4096 As I see it, the filesystem uses 1048576000 bytes (256000*4096) root@buster:/tmp# cp -pr /opt/Scripts/ /mnt/EXT2/ root@buster:/tmp# umount /mnt/EXT2 root@buster:/tmp# e2fsck -f /dev/loop0 e2fsck 1.44.5 (15-Dec-2018) 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 /dev/loop0: 457/64000 files (6.6% non-contiguous), 67098/256000 blocks root@buster:/tmp# resize2fs -M /dev/loop0 resize2fs 1.44.5 (15-Dec-2018) Resizing the filesystem on /dev/loop0 to 63894 (4k) blocks. The filesystem on /dev/loop0 is now 63894 (4k) blocks long. root@buster:/tmp# dumpe2fs /dev/loop0 | grep -E '(Block count|Block size)' dumpe2fs 1.44.5 (15-Dec-2018) Block count: 63894 Block size: 4096 After shrinking, the filesystem seems to be using 261709824 bytes (63894*4096) May I assume than in 100% of the cases, I can safely cut/shrink the underlying physical partition to these 261709824 bytes as well? Could it be that some filesystem blocks are still physically located after these 261709824 bytes?