[uClibc] Buildroot & inittar patch
pjlv at mega.ist.utl.pt
Tue Dec 14 17:30:39 UTC 2004
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
>>. gzipped ext2fs
>>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.
Pedro João Lopes Venda
email: pjlv at mega.ist.utl.pt
More information about the uClibc