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

[Vlado Plaga]

Hi Mark,

thanks for all the explanations! I thought a 24 MB ramdisk would really 
take 24 MB of precious RAM, even if it is mostly empty. As that is not 
the case (I did the dd/free check), there is not much left to be won by 
using the resizable ramfs, I think.

Mark Clarkson wrote:

> Yes, by using tmpfs instead of ramfs.
> ramfs was written first as a proof of concept, then tmpfs was written
> based on ramfs. See Documentation/filesystems/tmpfs.txt in the kernel
> sources. ramfs has no limit checking so can conceivably use all the
> available ram, but tmpfs can be limited so we can stop, say, a big
> log file killing processes.

Of course there had to be official documentation on tmpfs... but I did 
not find it. My apologizes to all of you!

> 
> You said earlier that ramfs did work but tmpfs did not
[...]
> See if CONFIG_TMPFS is set in the .config, hopefully it is not. This would
> be useful to know.

It was not set. But now I activated it under
File systems  --->
Pseudo filesystems  --->
[*] Virtual memory file system support (former shm fs)

>>The problems I have with the current ramdisk system are:

[...]

So the memory problem was never really a problem, as I just learned.

>>b) it is complicated and initialisation takes longer ("calculating
>>    number of inodes needed").
> 
> 
> I barely notice the time it takes to calculate the number of inodes
> needed but my machines range from 350Mhz to 2.5Ghz.

It takes some time on my PII 350, but not too long, that's true.

> Complicated? I find the whole lot very clever and complex indeed.

Sure, from the user point of view it is not a thing to worry about. It 
was just the long FAQ entry with 'set theory' and all that which made me 
think: wouldn't it be nice to get the same (or a better) result without 
all this? But you're right: its rather complex than complicated.

> So far I'd have to stick with 
> 
>   RAMTYPE="<tmpfs|ramfs|ramdisk|auto>"

Because you can have a kernel with tmpfs but without ramfs? But if both 
are available tmpfs would be better anyway, wouldn't it?

> To start I would probably keep /ram1 and /ram2 and only symlink
> from /ram[1|2] to the tmpfs/ramfs directory. I think this would
> 'waste' around 4mb in inodes but better than breaking everything.
> Hopefully bootcd2disk would not need modifying by doing it this
> way.

I personally don't really care about 4mb - firefox on the bootcd machine 
consumes 22mb at this moment...

Either stick to the current system or offer a ramdisk free option, I'd 
say. What do you win with an extra ramfs mount? I'll probably use larger 
RAMDISKs on my next bootcd (environmentalists don't worry: I'm using 
CD-RW) and remove the ramfs config. Does anything speak against using 
larger ramdisks (64MB)?

Maybe the comment in the /etc/bootcd/bootcdwrite.conf could be modified. 
Currently it reads:

# Both Ramdisks have the same size which is defined by RAMDISK_SIZE
#
# Example: If you want to spend 16MB for RAM Filesystems:
#   RAMDISK_SIZE=8192

Possible new version:

# Both Ramdisks have the same size which is defined by RAMDISK_SIZE
# but free space on ramdisks is still available as RAM to other
# applications
#
# Example: If you want to spend UP TO 32MB (+inodes) for RAM
# Filesystems:
#   RAMDISK_SIZE=16384

Another problem I had with bootcdwrite.conf: how do I add multiple new 
mount points to /etc/fstab. I circumvented the problem by using 
bootcdwrite's "change" mechanism, but it would still be nice to now (and 
document it), though.

Cheers,

Vlado