On 8/10/20 11:21 AM, Thomas Lange wrote:
>>>>>> On Fri, 7 Aug 2020 18:49:14 +0200, Thomas Goirand <z...@debian.org> said:
>
> > I don't think we need image as small as possible, to the last bits.
> > Quite the opposite, to make the resize-at-boot possible, we need to
> > leave a bit of free space. But even like that, we're talking about
> > saving half the space... That's half the storage space for providers,
> > for us, and many more (and also half the download time).
> I did some manual tests, but resize2fs did not saved much space, even
> when the FS is using only a small part of the FS. Here's an explanation why
> this may happen.
> https://unix.stackexchange.com/questions/456723/how-to-shrink-a-partition-below-the-minimum-size-reported-by-resize2fs
> That's why I asked if you have better results when using
> --automatic-resize within your tool.
Indeed, there's a 200MB overhead, though it doesn't have to be this way.
See by yourself:
root@shade>_ ~/img/new # fsck.ext4 -f /dev/mapper/loop0p1
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/mapper/loop0p1: 21692/57344 files (0.2% non-contiguous),
170432/204800 blocks
root@shade>_ ~/img/new # resize2fs -f /dev/mapper/${LOOP_DEVICE} 730M
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/mapper/loop0p1 to 186880 (4k) blocks.
The filesystem on /dev/mapper/loop0p1 is now 186880 (4k) blocks long.
root@shade>_ ~/img/new # mount /dev/mapper/loop0p1 /mnt/a
root@shade>_ ~/img/new # df -h /mnt/a
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/loop0p1 686M 620M 16M 98% /mnt/a
In fact, resize2fs forces some safety of adding 200MB, but in my case
above, I could force it (with -f) to remove the safety checks and go
below that limit...
Cheers,
Thomas Goirand (zigo)
