no relationship

tmpfs consist of swap + ram.

By default the limit is 60% in slax. There is a cheatcode for increasing this.

Take a look at the cheatcode section

documented on: 2007-05-30, Guest

here you go. You may need both. The 60% is of ram. Check if your swap partition is detected aswell

cat /proc/meminfo | grep Swap

If not on, then

swapon /dev/hdswap

Cheatcodes for SLAX

boot: slax changes=/dev/device

all changes you made in SLAX are kept in memory until you reboot. But with this boot parameter, you tell SLAX to use different device then memory for storing changes. You can, for example, format your disk partition /dev/hda1 with some Linux filesystem (eg. ext2) and then use changes=/dev/hda1 to store all changes to that disk. This way you won't loose your changes after reboot.

boot: slax ramsize=60%

documented on: 2007-05-30, Guest

They way I understood tmpfs, after a short read through, was that it is a filesystem that coordinates both your ram and swap (short storage if you like). So in that case i will assume yes. In my case (runing on a 1GB) I have so far only seen 5-10 mb of swap being used. But it is in use at least. (I will check how much is used in my low mem running qemu)

documented on: 2007-05-30, Guest

You were right. Using the cheatcode:

ramsize=100M

it actually changes the tmpfs size to 100M (makes sense) and I got heavily misleaded by the ramdisk_size keyword already present.

I have one more question.

Let say I had 10Gb of swap available at the end of my rc.local (fictional example). Would I be able to boot with a ramsize=5G, if i only have a couple hundred megs of ram?

documented on: 2007-05-30, turner

> I have one more question.

I honestly have no idea, apart from a feeling that it is based on ram and not swap. tmpfs just happens to coordinate whatever swap it may find, but I think the base is ram. So i would guess it would have tried to use all your ram, which again renders your system unstable.

I know there is also a remount possiblity for tmpfs while in system (becuase I have done it several times myself, but a while since last). You in/decrease the amount with the parameter -o size=

I guess you can play a bit with the remount command to try it out.

documented on: 2007-05-30, Guest

You will get a "out of ram" message for programs when you filled close to 128mb. But you CAN have 200m ramsize IF you make at least 200M swap file somewhere, in which case, all changes will get swapped into the swapfile and you can still have your 128mb ram, hence the reason why it doesnt care what size you set ramsize to.

The memory management is up to the kernel (and its quite good as far as i know). Because its a live cd, ram is shared by both programs AND the changes you make during a session. The idea is you should always have the same amount of swap as tmpfs (which for all intents and purposes is the total amount of changes you can make in a session before you have to delete some files or get out of memory). So you can make 1024M of tmpfs as long as you have 1024M of swap, which allows you to utilize the entire swap area for your changes and at the same time, programs wont run out of memory (unless they use more than your physical ram --->which means need larger swap file but bad performance).

an aside:

ramdisk_size is the size the system should reserve for initrd used during boot ( uncompressed ). Usually there is no good reason to touch this as it is already set for you by the live cd.

documented on: 2007-05-30, Guest