Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Since a tmpfs exists only in memory, can it become fragmented like memory can? Are there mechanisms to automatically defragment the memory, and thus increase - even slightly - the access speed of stored files?

share|improve this question
up vote 10 down vote accepted

As far as I know there are no ways to defragment a tmpfs filesystem (at least not on FreeBSD, Linux or Solaris).

Depending on the underlying implementation it's possible for tmpfs to become fragmented (e.g. some tmpfs implementations aren't in RAM - they chew up swap space: Depending on the allocation algorithm the swap space allocated could be fragmented and show a noticeable speed drop).

It's also possible for tmpfs in RAM to become "fragmented", but this isn't a practical concern: RAM is "fast enough" that you'd waste more CPU time trying to "defragment" it than you would lose accessing non-contiguous sections of RAM (no rotational delay to worry about, and the extra overhead for the MMU or equivalent to access non-contiguous sections of RAM versus a contiguous series of pages is small enough that you can probably neglect it.

Frankly if you're concerned about this level of performance you don't want to be using tmpfs anyway because the overhead of the VFS layer to make RAM look like a filesystem is many orders of magnitude worse than any memory fragmentation issues you may encounter (context switching, etc.).

share|improve this answer
I'm surprised about your "some tmpfs implementations aren't in RAM" statement. You might be confusing it with ramfs/ramdisks. All tmpfs implementations I'm aware of are backed by virtual memory, not (directly) RAM. – jlliagre Jul 1 '11 at 22:08
@jlliagre All *nix tmpfs implementations I'm aware of are backed out of "virtual memory" (RAM+Swap), but the allocation & paging strategies are up to the FS implementation - Solaris is a notable case that is in my experience fairly aggressive about marking tmpfs data as stale and paging it to disk. YMMV depending on how "hot" your temporary files are and how much RAM your system needs for other tasks though. – voretaq7 Jul 5 '11 at 15:11
AFAIK, there is no Solaris specific aggressive strategy as there is no specific handling at the VM layer in the first place. Virtual memory paging is handled equally regardless of what is stored on it. – jlliagre Jul 7 '11 at 8:54
@jlliagre - Yes, and Solaris (again, in my experience with 2.5.1 through 2.9) is aggressive about paging - the net result being stuff I had placed in /tmp wound up coming off disk more frequently than tmpfs in say Linux or the BSDs. This is my experience in the environments I was working in (which admittedly had lots of fat programs trying to get RAM). As always your mileage may vary, perform appropriate testing to determine how your environment will behave, keep chickens/goats/old workstations on hand for ritual sacrifices, yadda yadda yadda :) – voretaq7 Jul 7 '11 at 15:03

All tmpfs implementations are backed by virtual memory, not physical one. The question then doesn't make much sense as contiguous areas of virtual memory are very unlikely to be contiguous at the physical level and might not even present on RAM depending on the demand.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.