linux-ext4 - Re: [e2fsprogs] resizing to minimum was failed since 45a78b

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 30 Apr 2015 11:13:16 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Chanho Park <chanho61.park@...sung.com>
Cc:	darrick.wong@...cle.com, linux-ext4@...r.kernel.org
Subject: Re: [e2fsprogs] resizing to minimum was failed since 45a78b

On Thu, Apr 30, 2015 at 07:12:04PM +0900, Chanho Park wrote:
> 
> In my situation, I usually use the "resize2fs -M" when making a tizen
> platform image. As you know, like android, tizen also uses ext4 filesystem
> and flash the image from bootloader. Instead of flashing full image size, we
> only flash shrinked filesystem image to reduce flashing time and want to
> avoid download huge files. If the partition size is 3GB, we'll make a 3GB
> loop image and fill files into it. And I shrink the loop image to the
> minimum size and flash it to my phone. When first booting, the system will
> do resizing the partition to 3GB original size.

What I would recommend is to estimate how big the file system needs to
doing a "du -s" over the directory that you want to preload onto the
file system size, add say, 5% or so the file system metadata, and then
create the file system that way.  If the file system is close enough
to the right size, then resize2fs -M is much more likely to shrink the
file system to its minimal size, and also reduce the file
fragmentation that results from it.  (One of the better uses for using
resize2fs to slightly shrink a file system was to make room for the
LVM table at the end of the device, for example.  It's when you try to
take, say, a 1TB file system and shrink to a few megabytes that
resize2fs doesn't do a great job, because it really wasn't engineered
for that use case, and it's hard enough to make sure it does so in a
efficient and robust manner as it is.)

You can then take that file system and shrink to a size far larger
than what it was originally created as --- that works much better than
taking a large empty file system, shrinking it down to its minimal
size, and then expanding it to something bigger.  If necessary, you
can use the "mke2fs -E resize=15T" option to make sure enough metadata
blocks have been reserved so the file system can be expanded as much
as you would like.  By default we reserve enough metadata blocks for
the file system to grow by a factor of a thousand, so if you create a
super-tiny file system and then expect to grow it to a multi-TB size,
that mke2fs option will be useful.  It's not strictly necessary for
ext4 (although it was required for ext3), but it will result in a
slightly more efficient file system that will mount more quickly under
ext4.

So if your Tizen image is, say, 390 megabytes, I'd suggest creating a
400 megabyte file system, and load that up with the image.  If you
then use resize2fs -M, it should shirnk it down to something much
closer to 390M.

I suspect you will find that the resulting image will be far more
efficient than trying to start with a 3GB file system, shrink it down
to 400M, and then expand it backup to 3GB.

Best regards,

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html