tmpfs for /tmp and /var/tmp folders with 'changes=' cheat

[fanthom]

Wider explanation for 4 possible scenarios of booting Porteus when we have 1GB of memory (by 'aufs' i mean writable branch):
1) when Porteus is booted in "Always Fresh" mode then 60% of available memory is reserved for aufs (/ root). that means you can copy up to 600MB data to the system till your reach "out of space" message.
When you fill up aufs completely then 400MB is left for applications. if you copy only 200MB of data to the system then 800MB is available for use by apps.
2) when Porteus is booted in "Always Fresh' + "Copy2ram" cheatcodes then you have 600MB reserved for aufs minus size of actually used xzm modules. In case of filling up aufs completely there is always 400MB of RAM for use by the apps.
3) when Porteus is booted with "changes=partition/save.dat" then aufs size is the same as parition/save.dat and full 1GB of Ram is available for apps.
4) when Porteus is booted with "changes=partition/save.dat" + "Copy2ram" cheatcodes then aufs size is the same as parition/save.dat container and there is 1GB of Ram available for apps minus size of actually used xzm modules.

i hope it's not too complicated so far

Actual idea:
I'm thinking about mounting tmpfs in /tmp and /var/tmp folders when 'changes=' cheatcode is used.
this could be done by linuxrc during boot time - a proper info message could be displayed.

Adventages:
- faster KDE boot (LXDE boots fast enough so no benefit here). kde-4 creates few hundreds MB cache files in /var/tmp which could be done faster in RAM then in a save.dat file (usb sticks are rather slow in writing operations).
- faster work of all apps which keeps temporary files in /tmp folder
- less I/O operations on flash media which supposed to provide longer flash/ssd life (although i have read on aufs mailing list that Klaus Knopper could'n kill flash media in any way with hundreds of write operations, link:
http://sourceforge.net/mailarchive/mess ... d=28465723)

Disadventages:
- content of /tmp and /var/tmp folders is wiped off during every reboot so users must be remember to not keep any important data over there (who would keep them in /tmp folder??)
- 1GB of RAM available for apps is reduced by size of files which are kept in /tmp and /var/tmp folders.

My experience:
i'm doing this trick on gentoo box for very long time and can see only benefits. portage compilations are much faster when done in /tmp/portage folder (RAM) than on a hard drive.

Should i enable this feature for Porteus-1.1 or rather leave it as is?

[Hamza]

I would like to have a try with it!

[ponce]

I agree having tmps for this is good, but I think maybe you need plenty of ram for this approach...

kde-4 creates few hundreds MB cache files in /var/tmp

- 1GB of RAM available for apps is reduced by size of files which are kept in /tmp and /var/tmp folders.

In some cases, I think this could fill up all the RAM with stuff that goes in tmp (like package building temporary files...)

[Ahau]

Yeah, I've blown up my system a couple times recently by filling aufs (via /tmp with no changes=) full of slackbuild files...however, it does seem like a good idea on the balance (meaning, for those who aren't as idiotic as me ) maybe it could be implemented with a cheatcode to disable it (or, vice-versa, with a cheatcode to enable it)?

[ponce]

meaning, for those who aren't as idiotic as me

you're not alone, brotha!

[Hamza]

I am agree with Ahau's advice which is to add a cheatcode to enable/disable it.

Is it possible to use it for DE Only and only use this fast memory for module beginning with 00* which are the base modules ?

[fanthom]

thanks guys,

i must admit that enabling this feature by default would not be the best idea.
let's go with a cheatcode for users who knows how to control tmpfs/RAM in theris systems.

here is new /etc/fstab after using 'tmpfs' cheatcode

Code: Select all

# System mounts
aufs / aufs defaults 0 0 # AutoUpdate
proc /proc proc defaults 0 0 # AutoUpdate
sysfs /sys sysfs defaults 0 0 # AutoUpdate

# Device partitions
/dev/sr0 /mnt/sr0 iso9660 auto,noatime,nodiratime,suid,dev,exec,ro 0 0 # AutoUpdate
/dev/sda1 /mnt/sda1 ext3 auto,noatime,nodiratime,suid,dev,exec 0 0 # AutoUpdate
/dev/sda3 /mnt/sda3 vfat auto,noatime,nodiratime,suid,dev,exec,quiet,umask=0,check=s,shortname=mixed 0 0 # AutoUpdate

# Tmpfs for /tmp and /var/tmp folders
tmpfs /tmp tmpfs defaults,size=60%,mode=1777 0 0 # AutoUpdate
tmpfs /var/tmp tmpfs defaults,size=60%,mode=1777 0 0 # AutoUpdate

as you can see tmpfs will take 60% af available RAM so no chance to fill up whole RAM. this value is tunable by 'ramsize=' cheat (you can use 'ramsize=85%' and then tmpfs will be bigger)
'ramsize=' cheat has two functions now:
1) when 'changes=' cheat is not used, 'ramsize=' will decide about aufs / size (same as it was so far)
2) when 'changes=' cheat is used then aufs size is the same as partition/save.dat (it can't be tuned in any way) 'ramsize=' will decide about tmpfs size mounted in /tmp and /var/tmp folders (but only if 'tmpfs' param is provided)
Ahau - please update 'ramsize=' cheat description with info provided above. Also - i dont like 'tmpfs' cheat name so please propose better one. let me know if something is not clear.

here is 'df -h' output when 'tmpfs' cheat was used:

Code: Select all

Filesystem            Size  Used Avail Use% Mounted on
aufs                  185M  6.4M  169M   4% /
/dev/sr0              264M  264M     0 100% /mnt/sr0
/dev/sda1             185M  6.4M  169M   4% /mnt/sda1
/dev/sda3             286M  166M  120M  59% /mnt/sda3
tmpfs                 601M   12K  601M   1% /tmp
tmpfs                 601M   93M  509M  16% /var/tmp

as you can see kde-4 created 93MB of caches in /var/tmp (not few hundreds as i wrote in initial post but still a lot). these files were created in RAM and not on the hard drive (i have used /dev/sda1 for changes= cheat).

@Hamza
tmpfs is used for all modules activated during boot when copy2ram is used.
if users need extra functionality then i can tweak 'copy2ram' to load only base xzm's to RAM.

Cheers

[Hamza]

What about take 50% of RAM for System and take 10% (50%+10%=60%) for the tmpfs ?

[fanthom]

after analyzing 'df -h' output i have found a bug in tmpfs design:
- when you mount tmpfs with 60% of RAM in two places then you can fill up whole RAM by copying data to these folders.

size of the data is not summarized between folders
my impression is that system should stop copying the files to second folder when first one is full (60% is taken).
unfortunately this is not the case and you can hang the system by filling up second folder. copying stops when 100% of RAM is being used and this is not what we want.

soution as per today is to symlink /var/tmp to /tmp and mount tmpfs only in /tmp.
not sure if this is right from security point of view, etc...

other ideas?

@Hamza
i think you have missed the concept...

EDIT:\\
seems that i supposed to find out what's the purpose of /var/tmp folder at the first place:
http://www.pathname.com/fhs/2.2/fhs-5.15.html
it would make sense that kde-4 cache files are not updated too frequent between reboots.

i'm dropping this cheatcode - sorry for the fuss.

[sams]

I hope I'm not beating a dead thread with obvious info but...

I think the concept of /var/tmp is a bit odd on a live CD; most of the time I want all new state gone after a reboot. In a normal distro, you can expect that /var/tmp is cleaned sanely by a cron job rather than a reboot event, but I doubt most porteus users rely on "persistent temporary" state.

A trick I use on Slax is to overmount /tmp on /var/tmp:

Code: Select all

### bind overmount to replace original /var/tmp
mount --bind /tmp /var/tmp

I'm not aware of advantages of this over just symlinking, but this is a clean way to mount the same tmpfs on 2 mount points:

Code: Select all

$ mount | grep tmp
tmpfs on /tmp type tmpfs (rw,noatime)
/tmp on /var/tmp type none (rw,bind)

I don't have any recommendation on what the Porteus default should be here, people will probably try to run porteus on inadequate machines, go figure. All my systems have swap partitions, I even build my blank virtual machines with separate swap disks (non-persistent swap disks in vmware) so even if I spool to a tmpfs, it just continues onto the swap partition if it exhausts the RAM. This works really well, but it's not the environment Porteus will usually get in the wild.

cheers!

[fanthom]

thanks sams,

binding is definitely better than symlinking but it does not help with a fact that purpose of the /tmp and /var/tmp folders is quite different(check the link from the previous post).