[Bootcd-user] A Different RAM Disk Approach / RAMTYPE

[Vlado Plaga]

Mark Clarkson wrote:
> So tmpfs is a souped up ramfs

Maybe, but I'm not sure, because "df" only shows the tmpfs and not ramfs.

>, and a ramdisk is something completely
> different.

I think so too.

>  The only thing gained by using tmpfs is limit checking since
> we have no swap. (sounds useful to me)

What do you mean? By using tmpfs instead of ramfs?

> Scary! - This would make
> 
>     RAMTYPE="<tmpfs|ramfs|ramdisk|auto>"
> 
> to allow you to drop back to ramfs on the 2.6.6 kernel on PPC.

I don't think we have to account for PPC at all, the boot process is 
slightly different anyway (there is no syslinux package for PPC, for 
example). The problem was ramfs, I'm not sure whether it is still 
supported in 2.6 series kernels. Maybe I just switched something off in 
my kernel configuration, or there is a problem with ramfs in PPC...

But we don't need ramfs anyway, because I just checked what Knoppix does 
and it just uses one instance of tmpfs :

/ramdisk on /ramdisk type tmpfs

In that directory you find 'var' and 'home' subdirectories, in Knoppix. 
Of course 'etc', 'root' and 'dev' could also reside there, for bootcd.

The problems I have with the current ramdisk system are:

a) waste of memory: 12 are being used in my /ram1, but only less than 1
    MB get used in /ram2. tmpfs is supposed to use only as much ram
    as the files it contains need - by default the maximum is half of the
    available ram, which seems reasonable.
b) it is complicated and initialisation takes longer ("calculating
    number of inodes needed").

I already mount a tmpfs file system in /tmp (or /ram1/tmp, more 
precisely) because I put the firefox browser's cache in /tmp and so /tmp 
might need more space than /ram1 provides (/ram1/etc already uses much).

So my suggestion is:

RAMTYPE="<tmpfs|ramdisk|auto>"

...using tmpfs for kernels that support it, when "auto" is selected.

Cheers,

Vlado