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!
