tmpfs for /tmp and /var/tmp folders with 'changes=' cheat
- fanthom
- Moderator Team
- Posts: 5667
- Joined: 28 Dec 2010, 02:42
- Distribution: Porteus Kiosk
- Location: Poland
- Contact:
tmpfs for /tmp and /var/tmp folders with 'changes=' cheat
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?
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?
Please add [Solved] to your thread title if the solution was found.
Re: tmpfs for /tmp and /var/tmp folders with 'changes=' chea
I would like to have a try with it!
NjVFQzY2Rg==
Re: tmpfs for /tmp and /var/tmp folders with 'changes=' chea
I agree having tmps for this is good, but I think maybe you need plenty of ram for this approach...
fanthom wrote:kde-4 creates few hundreds MB cache files in /var/tmp
In some cases, I think this could fill up all the RAM with stuff that goes in tmp (like package building temporary files...)fanthom wrote:- 1GB of RAM available for apps is reduced by size of files which are kept in /tmp and /var/tmp folders.
- Ahau
- King of Docs
- Posts: 1331
- Joined: 28 Dec 2010, 15:18
- Distribution: LXDE & Xfce 32/64-bit
- Location: USA
Re: tmpfs for /tmp and /var/tmp folders with 'changes=' chea
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)?
Please take a look at our online documentation, here. Suggestions are welcome!
Re: tmpfs for /tmp and /var/tmp folders with 'changes=' chea
you're not alone, brotha!Ahau wrote:meaning, for those who aren't as idiotic as me
Re: tmpfs for /tmp and /var/tmp folders with 'changes=' chea
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 ?
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 ?
NjVFQzY2Rg==
- fanthom
- Moderator Team
- Posts: 5667
- Joined: 28 Dec 2010, 02:42
- Distribution: Porteus Kiosk
- Location: Poland
- Contact:
Re: tmpfs for /tmp and /var/tmp folders with 'changes=' chea
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
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:
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
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
'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
@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
Please add [Solved] to your thread title if the solution was found.
Re: tmpfs for /tmp and /var/tmp folders with 'changes=' chea
What about take 50% of RAM for System and take 10% (50%+10%=60%) for the tmpfs ?
NjVFQzY2Rg==
- fanthom
- Moderator Team
- Posts: 5667
- Joined: 28 Dec 2010, 02:42
- Distribution: Porteus Kiosk
- Location: Poland
- Contact:
Re: tmpfs for /tmp and /var/tmp folders with 'changes=' chea
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.
- 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.
Please add [Solved] to your thread title if the solution was found.
Re: tmpfs for /tmp and /var/tmp folders with 'changes=' chea
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:
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:
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!
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
Code: Select all
$ mount | grep tmp
tmpfs on /tmp type tmpfs (rw,noatime)
/tmp on /var/tmp type none (rw,bind)
cheers!
- fanthom
- Moderator Team
- Posts: 5667
- Joined: 28 Dec 2010, 02:42
- Distribution: Porteus Kiosk
- Location: Poland
- Contact:
Re: tmpfs for /tmp and /var/tmp folders with 'changes=' chea
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).
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).
Please add [Solved] to your thread title if the solution was found.