[Buildroot] [PATCH] manual: add section about dealing efficiently with big image files

[Yann E. MORIN <yann.morin.1998@free.fr>]

Peter, All,

On 2013-12-15 23:38 +0100, Peter Korsgaard spake thusly:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
>  >> I think that you should be using bigger block sizes, tools that
>  >> understand the filesystem layout or resize afterwards (E.G. resize2fs)
>  >> instead.
> 
>  > Not sure I follow you on that one. What if the user enters a large
>  > number of blocks for his ext2 filesystem? Those will be empty
>  > (zero-filled), but the image file will not be made sparse. So there is
>  > no 'fs resize' or such in the process.
> 
> What I meant was simply that if you want to end up with a filesystem
> with lots of free space and don't want to waste time writing zeroes to
> the unused areas, it is safer to:
> 
>  - create the filesystem spanning the entire partition yourself on the
>    fly (mkfs + tar xf output/images/rootfs.tar)
> 
>  - or resize fs to the full partition size after writing the image
>    (dd if=output/images/rootfs.ext2 + resize2fs)

I see, but in that case, we should no offer the user the ability to
specify the number of blocks to use for the ext2 filesystem, with
BR2_TARGET_ROOTFS_EXT2_BLOCKS, for example (and ext2 if the only
writable filesystem for which we do it).

Should I cook up a patch to remove BR2_TARGET_ROOTFS_EXT2_BLOCKS?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'