linux-ext4 - Re: flashing large eMMC partitions with ext4

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 21:05:57 +0300
From:	Amir Goldstein <amir73il@...il.com>
To:	Andreas Dilger <aedilger@...il.com>
Cc:	Round Robinjp <roundrobinjp@...oo.co.jp>,
	"Ted Ts'o" <tytso@....edu>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: flashing large eMMC partitions with ext4

On Wed, Jul 27, 2011 at 8:16 PM, Andreas Dilger <aedilger@...il.com> wrote:
> I still think that using resize2fs and removing/adding the journal provides the clearest way to create a small image. The only drawback is that this needs some post-processing steps after the image is written, so it may not be suitable for some workflows.
>

I must say this is a fun game to play :-)

I think it can be done without post processing.
If you know the estimated disk usage of the initial fs, say 1G:
1. mkfs a 1G ext4 fs with no journal, flex_bg=32, resize=4G
2. mount it and cp -a /foo/* /mnt/
3. use new online resize to resize fs to 4G (maintaining flex_bg layout)
4. add journal to mounted fs (.journal file should be allocated with goal 0??)

if my calculations are correct, the only blocks written beyond the 1G mark
are the super block backup copies, so truncating the resulting image to 1G
won't do any damage - even fsck shouldn't complain.

I have a task in my queue to test Yongqiangs new resize patches
(not the series that was just merged - the next series).
When I get to it I will try to play this game and let you guys know if
it worked.

Amir.

> Cheers, Andreas
>
> On 2011-07-27, at 10:40 AM, Round Robinjp <roundrobinjp@...oo.co.jp> wrote:
>
>>>> The flash will then contain _random_ data in the non-used blocks.
>>>> That is not a problem, right?
>>>
>>> Nope.  So long as the previously written (random) data on the card
>>> doesn't contain anything security sensitive.
>>
>> I understood.
>>
>>>> Although I have very small amount of files in my 4G image,
>>>> I see that the image has almost no zero-filled blocks.
>>>> Is that normal for ext4?
>>>
>>> It depends on how you created the image.
>>
>> I create the image like this:
>>
>> dd if=/dev/zero of=a.img bs=4096 count=1048576
>> mkfs.ext4 a.img
>> mount -t ext4 -o loop a.img /mnt
>> cp -a /foo/* /mnt/
>> umount /mnt
>>
>>>> Can zerofree.c recognize them as non-used blocks?
>>>
>>> Yes, it uses the block allocation bitmaps to understand what is used
>>> and non-used.
>>
>> Great.
>>
>> Thanks
>> Round
>> --
>> 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
> --
> 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
>
--
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