Re: flashing large eMMC partitions with ext4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 27, 2011 at 8:16 PM, Andreas Dilger <aedilger@xxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux