Comment 4 for bug 1857914

Revision history for this message
geole0 (geole0) wrote :

Hello
 I cannot reproduce the incident with this method

export LC_ALL=POSIX
sudo mke2fs -t ext4 /USB1910bis/fs.img 30G
mke2fs 1.45.3 (14-Jul-2019)
Creating regular file /mnt/USB1910bis/fs.img
Creating filesystem with 7864320 4k blocks and 1966080 inodes
Filesystem UUID: 2cf9eafb-628c-45d3-b452-6bdf785ae24d
Superblock backups stored on blocks:
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
 4096000

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

sudo mount -v -o loop /USB1910bis/fs.img /mnt
mount: /dev/loop12 mounted on /mnt.

#### It is necessary to copy files because when the partition does not contain any, it can shrink without difficulty

sudo ls -ls /mnt
total 20
 4 drwx------ 20 root root 4096 Jan 2 13:20 P2
16 drwx------ 2 root root 16384 Jan 2 12:56 lost+found

sudo umount -v /mnt
umount: /mnt unmounted

sudo e2fsck -fy /USB1910bis/fs.img
e2fsck 1.45.3 (14-Jul-2019)
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
/USB1910bis/fs.img: 3929/1966080 files (0.4% non-contiguous), 3978206/7864320 blocks

sudo resize2fs /USB1910bis/fs.img 20G
resize2fs 1.45.3 (14-Jul-2019)
Resizing the filesystem on /USB1910bis/fs.img to 5242880 (4k) blocks.
The filesystem on /USB1910bis/fs.img is now 5242880 (4k) blocks long.

sudo e2fsck -fy /USB1910bis/fs.img
e2fsck 1.45.3 (14-Jul-2019)
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
/USB1910bis/fs.img: 3929/1310720 files (0.4% non-contiguous), 3937075/5242880 blocks

sudo mount -v -o loop /USB1910bis/fs.img /mnt
mount: /dev/loop12 mounted on /mnt.