very large ram disk problems -- swapping, caching, and why tmpfs and not ext2 or reiserfs

Phil Meyer pmeyer at themeyerfarm.com
Tue Oct 3 23:31:33 UTC 2006


Matthew Kirk wrote:
> ...
> 2.  I understand, through the "grape vine" that a ram disk built with tmpfs
> can have its contents swapped.  I also understand this is not true of ext2
> or reiserfs.
>
> Is that correct?    
>
> My primary concern with using tmpfs has to do with swapping -- I'm using a
> ram disk for a variety of reasons, but one of them is to avoid having any
> writes to the file system for staging files and to ensure that certain files
> are present for processing and don't need to be re-loaded.  Swapping defeats
> that purpose. I can't use /tmp because I also need to pre-reserve space.
>   
In another thread earlier, I wrote a small piece on virtual memory.  I 
don't want to repeat all of that here, just a quick summary so you know 
what your options are.

Simply put, RAM+swap = virtual memory.

The kernel keeps track of where the physical line is between RAM and 
swap, but for some applications its all one space.  tmpfs is one of 
those applications.

The kernel will favor RAM for all applications in virtual memory, and 
will use the swap space only when RAM is exhausted according to some 
complex rules.  Basically everything in virtual memory can grow and 
shrink at will.  The kernel at one end, and disk cache and other non 
priority applications (like tmpfs) at the other end.  Each of the 
applications and methods used in virtual memory have minimum space 
requirements associated with them.  Swapping does not occur until ALL of 
those minimums are reached.

So if you have lots of RAM, tmpfs is very much a RAM disk.  If you run 
short on RAM alot then a tmpfs file system will perform about like any 
other, except it will be doing physical read a writes to the swap area.  
Filling up a tmpfs file system is a good way to cause lots of trouble. :)

It is my belief that tmpfs first appeared on Solaris.  At least that is 
where I saw it first.  We used it by default to mount /tmp on all 
desktop systems, especially developer systems where lots of small files 
are constantly affected, and the compilers write lots of temporary 
files.  tmpfs in those types of systems basically fights disk cache for 
RAM space and it works very well.  However, copying large files to /tmp 
can be problematic.  By default, we ran scripts to clean out anything a 
week old in /tmp on all of those systems.

Here is a link to a munin example page:
http://munin.ping.uio.no/ping.uio.no/beate.ping.uio.no-memory.html

Note that the bright green at the bottom is the apps layer.  The kernel 
layer is actually underneath that, if you can imagine it.  The kernel 
layer is static, so munin does not show it.
The dark blue near the top is 'free' or unused memory.  Notice that the 
disk cache (orange)    pushes up into 'unused' until it is gone.  That 
is completely normal and desirable.  Notice also that this system has 
some swapping activity.  This system is NOT a candidate for tmpfs unless 
that swap activity is from a memory leak that has been corrected but the 
system has not been rebooted since it was fixed.  But notice the size of 
cache (orange) comparative to the other elements.  On other systems that 
don't show swapping, I would guess that they would be prime candidates 
for tmpfs.

Good Luck!




More information about the fedora-list mailing list