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:	Wed, 27 Jul 2011 13:28:55 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	Round Robinjp <roundrobinjp@...oo.co.jp>
Cc:	Ted Ts'o <tytso@....edu>, Andreas Dilger <aedilger@...il.com>,
	Amir Goldstein <amir73il@...il.com>,
	Yongqiang Yang <xiaoqiangnk@...il.com>,
	linux-ext4@...r.kernel.org
Subject: Re: flashing large eMMC partitions with ext4

On 2011-07-27, at 12:08 PM, Round Robinjp wrote:
> I have got some nice ideas from you.
> I summarize them here and add some comments.
> 
> o  Idea from Andreas
>    Create minimal image, flash write, then resize2fs
> 
>    -> Very straight forward idea.
>    -> Post-processing after flash writing adds some difficulties.

It would be possible to do the post-processing inside the kernel
initrd at first boot.  Adding the journal to the root filesystem
would need to be done before it is mounted, if your image does not
have the journal.  Adding a call to "resize2fs" if the filesystem
is not as large as the partition it is in is easy, and can be done
while the root filesystem is mounted.

> o  Idea from Ted
>    Zero-fill the non-used blocks.
>    Make the flash writer write only non-zero blocks.
> 
>    -> Very straight forward idea.
>    -> Flash writer needs to support this.
> 
> o  Idea from Amir
>    Set flex_bg to 32.

To be strictly correct, this should be (final_size / 128M).  For your
case of 4GB final size, a flex_bg factor of 32 is indeed correct.

You may also want to reduce the number of inodes in the image, by using
"-i" to specify a larger average file size.  Default is only 16kB average
file size, but if you know the usage model (e.g. MP3s or photos 4MB in
size) then you can create far fewer inodes (e.g. mke2fs -i 1048576).

>    Set sparse_super.
>    Allocate journal from group 0 (feasibility unclear)

If you are up for some coding to change mke2fs, being able to specify a
goal block for the journal is something that I've been interested in for
some time already.  Adding an option like "-J goal=0" would tell mke2fs
to start searching for free blocks at block 0 instead of the new default
journal goal of (blocks_count / 2).  I don't think this would be very
difficult to implement, and would very likely be accepted by Ted.

>    Truncate the image.

You should verify with dumpe2fs to check that there are no blocks in
use beyond the truncate range.

I like Amir's new suggestion better - create a small filesystem, fill
it up, then resize to the final size, then truncate down to the original
small filesystem size.  Depending on how the resize is done, it should
be possible to have all of the end groups be completely empty.

>    -> Feasibility and effectiveness is unclear.
>    -> Good side is legacy flash writer can be used.
> 
> o  Idea from Yongqiang
>    Delete journal before flash write and later add it back.
> 
>    -> Post-processing after flash writing adds some difficulties.
> 
> I will examine all of these to find out a suitable solution.
> Thanks
> Round


Cheers, Andreas





--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ