Empty Tmp Folders?

[Was_Just19]

When using RAM as /tmp is there some fail-over which would cause the OS to use physical Swap space should available RAM being to dwindle?

[Bald Brick]

When using RAM as /tmp is there some fail-over which would cause the OS to use physical Swap space should available RAM being to dwindle?

Yes. If tmpfs (the tmp filesystem) runs out of RAM it will use swap. From http://www.ibm.com/developerworks/library/l-fs3.html:

As I mentioned above, tmpfs can use both RAM and swap. This might seem a bit arbitrary at first, but remember that tmpfs is also known as the "virtual memory filesystem". And, as you probably know, the Linux kernel's virtual memory resources come from both your RAM and swap devices. The VM subsystem in the kernel allocates these resources to other parts of the system and takes care of managing these resources behind-the-scenes, often transparently moving RAM pages to swap and vice-versa.

A tmpfs filesystem grows and shrinks dynamically. I haven't checked what the default maximum size is. I vaguely remember it is half your RAM, but in any case you can easily change that. (See the IBM article.)

And if /tmp doesn't need that amount of memory it won't hog it: it will be free for applications that need it.

[Was_Just19]

Thanks Blackbird .......  I am trying to devise an optimum set up of /tmp for this desktop - to test it.

I have in mind a relatively small RAM /tmp ....  maybe 100MB to start but quite likely less would do.

That should be sufficient for normal day to day use.

Virtual Memory being the sum of the ramfs and Swap, there should only be a gain in speed for normal use, and Swap used as before for the heavier use ......  if I am getting this.

I wonder also what the consequences, if any, there are for S2R and S2D.

....  methinks I know too little about this to be even posting ...... 

Best thing is to try a few settings and watch for any baddies appearing 

[Bald Brick]

I have in mind a relatively small RAM /tmp ....  maybe 100MB to start but quite likely less would do.

Should be enough for most purposes if you just reboot now and then. (But what about remastering? But there you are the expert.)

[Was_Just19]

I have in mind a relatively small RAM /tmp ....  maybe 100MB to start but quite likely less would do.

Should be enough for most purposes if you just reboot now and then. (But what about remastering? But there you are the expert.)

Remastering ......  I guess that should depend on how the Vir Mem is handled by the OS ......  would the remastering use the Swap space in the absence of available RAM for /tmp?
That link from IBM seemed to imply it would ........  but I may be misinterpreting .....

tmpfs and VM
Let's take a look at some of tmpfs's more interesting properties. As I mentioned above, tmpfs can use both RAM and swap.

EDIT
          I remember a long time ago someone said what the defaults were for the tmpfs in PCLOS ....  but now cannot remember .....  if anyone knows please post .....  must do some searching myself ...

[Was_Just19]

OK, for those still interested in this subject, I am trying to figure out a few things, and as usual having some difficulty. 

The fstab entry for /tmpfs apparently determines the MAX size the temp can be.
When used with Defaults in the fstab line that means half of the recognised memory in the system.
You can also manually determine the size of the temp fs by replacing 'defaults' with a size .....  size=256m ....  for instance.
Your temp is now limited to 256MB!

What I was trying to achieve is that my temp fs would use that 256MB until filled, and then begin to use the Swap space available for anything extra.
That does not happen automatically, so obviously some more must be done ......  but what?

One answer would appear to be to make the temp fs entry in fstab equal to half of the fitted RAM, plus a large proportion of the Swap space.
So if I have 4GB Swap, and 4GB RAM, I could make the temp fs    size=3g    .....  that should now ensure that if /tmp runs out of RAM it will use Swap in addition.

Of course what I would like to do is to allocate 256MB of RAM only, and make the max size of the temp fs    1256m

So now I look at the other entries in fstab, and notice this  'none'  entry.
What does that do?
Is that the entry that limits the RAM that can be used?

I have not yet found sufficient information to determine what exactly this is doing .......  so if anyone has ideas please post, thanks.   

regards.

[Bald Brick]

So you want a smallish maximum size for /tmp in RAM but you also want it to be able to grow larger utilizing swap. But does it have to be swap? Won't any free space on the hard drive do?

I think the IBM article I linked to gives you a solution (even if it doesn't use the swap partition): look for the heading "Bind mounting parts of filesystems".

(I've never used bind mounting, but I suppose I must soon.)

[Was_Just19]

So you want a smallish maximum size for /tmp in RAM but you want it to be able to grow larger utilizing swap. But does it have to be swap? Won't any free space on the hard drive do?

I think the IBM article I linked to gives you a solution (even if it doesn't use the swap partition): look for the heading "Bind mounting parts of filesystems".

(I've never used bind mounting, but I suppose I must soon.)

I have been taking a different approach      since I last posted.

The  tmpfs  is dynamic.
It is non-persistent.

So rather than worrying about how much RAM it is using, I can depend on it to page out of its RAM, some stuff, when there is a need for the RAM for other processes or apps ......  or so I am reading into the info.

So, now I am considering a situation where, the /tmp directory is just a link to a tmpfs mounted at /dev/shm.

I can make the tmpfs the sum of my spare RAM plus most of my Swap, and not only should it use it all intelligently, but it should be wiped at reboot.

I would appreciate it if you would shoot holes in that idea rather quickly ......  before I bork my install attempting something like it   

The tmpfs creates and mounts OK from fstab.
I got that far 

Code: [Select]

$ df
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda6              21G  7.6G   12G  40% /
/dev/sda7              31G   16G   16G  50% /home
tmpfs                 6.0G  2.3M  6.0G   1% /dev/shm
The user tmp directories are linked to /tmp, as I understand it.
So if /tmp was just a link to /dev/shm .......  would all temp stuff not end up in tmpfs and be lost on reboot?

Just present thoughts ........

[Was_Just19]

Decided to do some tests on this idea.

For some reason my users /tmp did not seem to be a link but a proper directory 

I created a link from the user account to /dev/shm, and deleted /tmp from there and named the link /tmp.

I decided that it was prudent to try this with a user only at first 

It appears to be working, so will continue to see what happens.

regards.

[Bald Brick]

Decided to do some tests on this idea.

For some reason my users /tmp did not seem to be a link but a proper directory  

After some update or perhaps even after my first install of PCLinuxOS 2010 some tmp folders that used to be links to /tmp were just normal directories. The system, of course, worked well that way too, but I recreated the links as soon as I realized they weren't there.

I created a link from the user account to /dev/shm, and deleted /tmp from there and named the link /tmp.

I take it that what you deleted and created was ~/tmp and not /tmp?

I decided that it was prudent to try this with a user only at first  

Sounds sensible. (Before you wrote that I didn't understand why making /tmp a link to /dev/shm would be preferable to just mounting a tmpfs on /tmp.)
[/quote]

[Was_Just19]

Decided to do some tests on this idea.

For some reason my users /tmp did not seem to be a link but a proper directory  

After some update or perhaps even after my first install of PCLinuxOS 2010 some tmp folders that used to be links to /tmp were just normal directories. The system, of course, worked well that way too, but I recreated the links as soon as I realized they weren't there.

I created a link from the user account to /dev/shm, and deleted /tmp from there and named the link /tmp.

I take it that what you deleted and created was ~/tmp and not /tmp?

I decided that it was prudent to try this with a user only at first  

Sounds sensible, even if I don't understand why making /tmp a link to /dev/shm would be preferable to just mounting a tmpfs on /tmp.

Baby steps 
I wanted to be easily able to back out of it if necessary.

I am also unsure if future updates might affect things .....  I just do not know.

Presently I can see no reason not to also link  /tmp   to the tmpfs.

Some simple tests prove to me that the contents are correctly discarded after a reboot.

I also did a remaster on this install, using the tmpfs as the 'tmp' of the mylivecd script.

This PC is a 3.2Ghz P4 with 3.4GB RAM.
For the 1Hr 07Mins it took to create the 2.3GBs ISO, the CPU was maxed out.

The RAM usage was not what I expected .....  it peaked at 1.3GBs and dropped back to less than 500MiB after the ISO was created (normal).

So after a few tests and reboots this seems to do all I need ......

Thanks for the assistance in getting this right in my head   

regards.