1. Introduction
The temporary file system (tmpfs) plays a crucial role in the Linux ecosystem by providing a temporary file storage facility directly in the system’s Random Access Memory (RAM) or swap space. This feature significantly speeds up read and write operations for temporary data, compared to traditional storage on physical disks.
In this tutorial, we’ll explore the mechanics of tmpfs. We’ll start with its fundamentals, benefits, and typical use cases. Then, we’ll discuss how to manage tmpfs effectively, from configuring its size to understanding its behavior when full.
Finally, we’ll touch upon the critical aspect of memory management, especially the prioritization between tmpfs and active applications. Let’s get started!
2. Understanding tmpfs
tmpfs is designed to speed up read and write operations by storing temporary data in memory (RAM) or swap space rather than on a hard disk drive (HDD) or solid-state drive (SSD). It’s widely used across Linux distributions for various purposes, such as storing session data, caches, or any other temporary data that benefits from quick access.
A typical mounting point for tmpfs is /dev/shm, which software applications use to share information between processes quickly and efficiently.
Notably, the primary advantage of using tmpfs is its speed. Since RAM is significantly faster than disk storage, operations on files stored in tmpfs are quicker, reducing the time required for processes that rely on temporary data storage. This can lead to noticeable performance improvements in applications that frequently read from or write to temporary files.
Another critical feature of tmpfs is its volatility. Any data the system stores in tmpfs is lost upon reboot, which naturally clears temporary files that we no longer need, helping to keep the system clean without manual intervention.
3. What Determines tmpfs Size
By default, the size of a tmpfs instance is typically set to half of the available physical RAM on the system. This setting balances the need for fast, temporary storage against the necessity of preserving enough RAM for other applications and system processes.
However, to discover the size currently allocated to our tmpfs, we can use the df command with the -h flag:
$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 7.9G 1.2M 7.9G 1% /dev/shm
...
Our output displays disk space usage in a human-readable format. Among our list, we’ll find the entries for tmpfs, including /dev/shm, showing the total size, used space, and available space.
3.1. Editing the /etc/fstab File
We can customize the size of tmpfs via mount options. This is particularly useful for systems with specific performance requirements or limitations. These options are specified in the /etc/fstab file, which controls the mounting of file systems at boot time.
Therefore, we can edit the /etc/fstab file with any text editor like nano, vi, or gedit to manually set the size of the tmpfs instance:
$ sudo vi /etc/fstabThen, in the file, we add our preferred size configuration.
Let’s see an example of how to set the size to 2GB for /dev/shm:
# File /etc/fstab
...
tmpfs /dev/shm tmpfs defaults,size=2G 0 0This line tells the system to mount the /dev/shm directory with a tmpfs file system, setting its size to 2GB (size=2G) in the options field. The defaults option refers to the default mounting options. Then, the numbers 0 0 at the end of the line are dump and fsck options, respectively, which we don’t typically use with tmpfs.
Afterward, we can save the changes and exit the editor.
To apply the changes without rebooting, we can remount the tmpfs with the new size:
# Remount tmpfs after modification
$ sudo mount -o remount /dev/shmWith this, we effect our changes without a need for reboot.
3.2. Temporary Adjustment
Alternatively, we can dynamically change the size of an already mounted tmpfs instance, e.g., /dev/shm:
$ sudo mount -o remount,size=2G /dev/shmHowever, unlike our previous interaction with /etc/fstab file, this command doesn’t permanently change the size. It will last until the next reboot or until we manually change it again. This provides significant flexibility for changing system requirements without rebooting or permanently altering the fstab configuration.
To make permanent changes, we have to stick with editing the /etc/fstab file.
Ultimately, as system administrators, we can tailor resource allocation to match the system’s workload, ensuring optimal balance between temporary storage and memory available for applications. This customization can lead to significant performance improvements, especially in systems where memory resources are a critical bottleneck or where we heavily utilize tmpfs.
4. Managing tmpfs Capacity
The flexible nature of tmpfs means it adapts to the demands placed upon it up to its maximum allocated size.
But what happens when tmpfs reaches its capacity?
4.1. The ENOSPC Error
Should tmpfs become full, it behaves like a conventional disk-based file system. It refuses new writes and returns an Error No Space (ENOSPC) to any operation we perform that attempts to exceed its capacity. This mechanism prevents tmpfs from consuming all available system memory, which could lead to system instability.
However, in scenarios where the system is under significant load, and tmpfs is full, Linux’s memory management kicks in. If we have that configured, the system may start using swap space to offload less frequently accessed data from RAM, including data from tmpfs.
Nonetheless, this can lead to performance degradation, as swap space on a disk is much slower than RAM.
4.2. Preventing Deadlock Situations
We must understand that while tmpfs can use swap space, oversizing our tmpfs instances beyond the sum of our physical RAM and swap space can lead to a deadlock situation. In such cases, the system becomes unresponsive due to insufficient available memory.
To prevent this, we must monitor the usage of tmpfs and adjust its size or manage the stored data appropriately.
One way to view the current usage of tmpfs and swap space is through the free command with the -h option, which shows the total amount of free and used memory and swap space in the system:
$ free -h
total used free shared buff/cache available
Mem: 15Gi 3.5Gi 8.2Gi 1.2Gi 3.3Gi 10Gi
Swap: 2.0Gi 500Mi 1.5Gi
As we can see from our output:
- total – shows the total amount of memory or swap space available on the system
- used – indicates how much memory or swap space is currently in use
- free – displays the amount of memory or swap space that is not in use
- shared – shows memory that multiple processes may simultaneously access
- buff/cache – represents memory used by the kernel for buffers and caching, which is a mechanism to speed up processes by keeping frequently accessed data in memory
- available – estimates how much memory is available for starting new applications without swapping
In this case, despite the used memory being 3.5Gi, there’s about 10Gi available for new applications. This discrepancy arises because the system can reclaim memory from buffers and caches if needed.
5. tmpfs vs. Applications: Memory Management and Prioritization
The Linux kernel employs sophisticated memory management techniques to meet system and application needs, balancing performance and stability.
When prioritizing memory usage, the kernel dynamically adjusts to the current demands, influenced by the total usage of tmpfs and the memory requirements of running applications.
5.1. Memory Prioritization Mechanics
Linux treats tmpfs memory similarly to the memory used by applications.
When system memory becomes scarce, the kernel’s memory manager decides, based on usage patterns, which data to keep in RAM and which to offload to swap space. Here, frequently accessed data (“hot” data) is held in RAM for fast access, while less frequently accessed data (“cold” data) may be moved to swap space.
Moreover, this prioritization is evident when tmpfs and applications concurrently demand more memory than is physically available.
For example, suppose tmpfs is consuming a significant portion of memory (say, 40% of physical RAM) and running applications suddenly require more memory (e.g., 70% of physical RAM). In that case, the kernel will decide what to keep in RAM and what to swap out based on the access patterns and importance of the data.
5.2. Managing Memory Effectively
As system administrators, we might need to manually adjust the size of tmpfs or the system’s swapiness behavior (the kernel parameter determining how aggressively memory pages are swapped to disk) to ensure that critical applications have enough memory and maintain system performance.
To do this, we can use monitoring tools like vmstat and top to provide real-time insight into memory usage and help identify when adjustments are necessary.
Notably, for systems with high tmpfs usage, we can increase physical RAM or configure more swap space to accommodate the demands of both tmpfs and applications.
Conversely, for applications that require maximum performance with minimal latency, we can minimize tmpfs usage or adjust the system to favor application memory.
6. When to Use ramfs Over tmpfs
While tmpfs is a versatile and powerful tool for managing temporary data in memory, it’s not the only option available on Linux systems.
An alternative we can consider is ramfs, another in-memory file system that shares some similarities with tmpfs but also has distinct differences that make it suitable for specific use cases.
ramfs is similar to tmpfs in that it stores files in RAM, providing fast access to temporary data.
However, unlike tmpfs, ramfs doesn’t have a size limit. This means that ramfs will continue to consume memory as files are added without any checks, which can lead to a situation where ramfs consumes all available system memory.
Nonetheless, we should use ramfs if we need a temporary storage solution without size restrictions and are confident in our ability to manage the memory usage manually to prevent the system from running out of RAM.
On the other hand, we should use tmpfs if we prefer a more manageable in-memory storage solution that automatically limits its size, thereby reducing the risk of exhausting system memory.
In all, we must weigh these considerations carefully when deciding which in-memory file system to use, as the choice will significantly impact our system’s performance and stability.
7. Conclusion
In this article, we’ve explored the dynamics of tmpfs within the Linux environment, from its configuration and usage to the considerations necessary for balancing system performance with memory demands. tmpfs offers a powerful means to leverage RAM for temporary storage, enhancing performance for disk I/O-intensive applications.
Also, we briefly considered ramfs, an alternative with its advantages and challenges, highlighting the importance of choosing the right in-memory storage solution based on specific system and application needs.
The key takeaways include the significance of configuring tmpfs size appropriately, monitoring system memory to ensure stability, and the potential benefits of employing alternative solutions like ramfs for our specific use cases.