[uClibc] Buildroot & inittar patch

Pedro Venda pjlv at mega.ist.utl.pt
Tue Dec 14 17:30:39 UTC 2004


hello,

thanks for reply :-)

Thomas Cameron wrote:
>>when I read that message in the linux-kernel ml, I thought of 
>>the same... but 
>>what do you gain with it? is there a real overhead spared 
>>with tarfs filesystem 
>>that you waste with gzipped ext2fs?
> 
> 
> Simplicity, for one. All you do is feed a .tar.gz to the kernel, and it will
> create a tmpfs filesystem for the initial filesystem. For me, this means I
> can have a read-write filesystem that is limited in size only by memory
> constraints or those I manually implement.

I will review it, but I remember that one of the issues of tmpfs was read-only 
support... people argued that implementing rw support would be hard. maybe 
that's changed... or maybe that was only for tar.gz and not tar..

> Another note of interest, which also answers half of your next question, is
> that tmpfs is read-write, while images based on cramfs and squashfs. This
> means any changes to the filesystem done by a user can cimply be tarred up,
> and saved over the original inittar file. Again, this is convenient for
> simplicity's sake, You no longer have to package such tools as genext2fs, or
> any of the others.

Didn't know of such tools. Never thought of implementing init ram disks and 
writing changes to them. I thought that was not the expected use.

> 
> 
>>In the same subject what are the pros and cons of using these 
>>filesystems in the 
>>initrds:
>>. gzipped ext2fs
>>. cramfs
>>. squashfs
>>. tarfs
>>
>>What stops one from using any other filesystem? overhead?
> 
> 
> Overhead is one issue, yes. For instance, if you create a root image with an
> ext2 filesystem and an exact duplicate based on the minix filesystem you
> will notice that the minix image is smaller. It's structures are smaller,
> and it has fewer features than ext2.
> 
> With regard to cramfs, squashfs, and a host of other compressed filesystems,
> these are read-only. The same applies to the crypto-loop filesystem images
> that some projects use. This means you have to package tools into the image
> to recreate itself when changes are made. This, of course, takes up space
> and adds complexity.
> 
> In the end, however, the answer is the same as any other in Linux Land. It
> all comes down to personal preference. Many of us are creatures of habit,
> and many of us are bit-squeezers. I like to make things as simple and small
> as possible, and therefore I have chosen to use tmpfs as my root filesystem.
> YMMV, as always.

thanks. Will try that.

regards,
pedro venda.
-- 

Pedro João Lopes Venda
email: pjlv at mega.ist.utl.pt
http://arrakis.dhis.org



More information about the uClibc mailing list