Have you ever heard of tmpfs on Linux? It's that little temporary filesystem that resides in memory and is installed by default on Linux distributions. Ultra-fast but regularly limited in size. Can you easily grow? Know more!
What is it tmpfs?
Everything within a computer has a certain native operating speed. It starts with the CPU (the Central Processing Unit) On your computer, which has a set of L1-Lx caches (Level 1 at Level x), they are very small (as an example, 16 Kb) but ultrafast (and probably ultrafast). -costly).
After the CPU caches, are the main memory banks, that are still much faster (and byte for byte more expensive) that the hard disk, etc. As you can see, it's about cost versus size versus speed. The general rule of thumb is that cost increases as speed increases and size will decrease to limit cost, etc.
If you stored all your data inside your computer's main memory chips, which is technically very feasible and quite simple to do, his work literally fly compared to when using single disc, since memory chips are much faster than most hard drives.
Despite this, there are some technical limitations with this. Once you turn off your computer, your files will disappear. An unrecoverable application failure could be enough for you to have to restart your computer and lose your files. At the same time, you could never turn off your computer again, unless it had some advanced features (that does not exist as far as I know) to keep your files on memory chips, equivalent to a BBU compatible cache (Battery backup unit) in a raid controller.
Despite this, note that there is an equivalent feature (but not identical) to this one that you may already be using: when you suspend your system to RAM (using to sleep or other equivalent terminology used by operating systems), some power will be continuously supplied to your memory chips to keep your data current.
Subsequently, when you reboot your system, you can pick up where you left off. But shutting down while keeping memory content is generally not used with computers. Potentially, could be used by smart tablets, even though it could be argued that such states are not true off states, but rather low power states.
Having clarified how, in general terms, storing your files on memory chips is probably not a solid idea, there are other uses where it might be helpful. As an example, when testing / program quality control, it is likely to start and close the program under test usually.
These files are temporary and of little individual value. (unless a bug is found, at which point the data can be copied back to the main disk) and, as such, could be stored on your memory chips. This is what tmpfs is and does: It is a temporary filesystem inside your memory. Some of you might immediately object and say: “That is not true”, and they would be right. continue reading.
Those who objected could have immediately made the claim that the tmpfs space is not guaranteed to be in memory, and this is true. You can see tmpfs like a hybrid between a real RAM disk (a disk created in volatile memory) and real permanent disk storage. In certain cases, the linux kernel will swap the contents of tmpfs in the system swap space, that could be on the disk. This is done transparently (without the need for user interaction).
For more information on how to configure a RAM disk, see our guide How to create a RAM drive in Linux.
Your current tmpfs Size
Now that we have tmpfs better defined space, Let's take a look at the current size of your tmpfs space. Could you think of him tmpfs system as a virtual drive, temporary and volatile. You can see the space in use using df -h (file system disk space usage (df) in human readable format, Thanks to the -h option):
df -h | grep -Ei 'shm|size'
Here we use df -h (explained above) combined with a pipe (|) to send the output resulting from the df -h yet grep, using an extended (-E) format regular expression in a case-insensitive way (-i or simply I when combined with another alternative) to choose the top title (that includes the word Size) and any line that includes the text shm.
The reason why grep shm is that almost always, as we can also see in the output here, tmpfs space is allocated to the filesystem directory /dev/shm. If the above command does not produce any output, just run df -h and review the total results to search tmpfs space, yes there is.
Note that, by default, the operating system will also assign / will set some tmpfs spaces, that could, as an example, map / ride the /sys/fs/cgroup, /run and /run/lock directories. Don't try to edit them.
With respect to /dev/shm and other directories, note to see these folders in the operating system directory structure [tree] does not mean that the files are truly / physically stored on disk in some /dev/shm directory!
It simply means that, according and in line with the standard Linux way of being able to mount drives (o for this case, tmpfs) in any directory in the filesystem hierarchy, if there were files in that directory before mounting , they just wouldn't be visible until the mount point was dropped.
In this particular system, the tmpfs the space is of 32 GB and almost everything is not used. What little is in use (166 MB) is the goal table / index of the directory itself, which is invisible to users, but it is in place to be able to store files in the file system structure. The size of the tmpfs it is, by default, half the system memory for certain operating systems.
This is a pretty big tmpfs and it would only be technically justified, until a certain point, in a system with, as an example, 40 GB or more of physical memory, although, depending on the circumstances, a particular use case might justify other configurations. Usually, I recommend keeping the tmpfs space less than, Let's say, the 70-80% of the memory, and that percentage would be significantly lower if the RAM (Random access memory, another abbreviated way or way of referring to system memory) I was small to start.
The reason for this is that you want to make enough memory space available to run other programs, operating systems and software services.
As an example, I would not want to award the 80% of memory if your system had 2GB of memory, since this would probably leave very little for other things to work properly or at all. And, Conversely, has a lot of 256 GB of memory, including the 90% of that (230,4 GB) I would leave some good ones 25 GB available, that, depending on the use case, could (or not) be enough.
In summary, I recommend that you always adjust the size of tmpfs according to 1) how much space do you really need in tmpfs, 2) how much memory is on your system and 3) how much real memory other apps are using at the same time from tmpfs (including your operations, services, etc.). Experience with all these things helps here.
Extension tmpfs in your system
Now that we know the size of the stream tmpfs volume and what size to give it in the future using some of the considerations provided in the last paragraph above, we can take a look to enlarge (or reduce) our tmpfs space.
Doing it is quite simple. All we will do is, instead of the operating system automatically configuring the /dev/shm tmpfs space for us, define it statically in place in the /etc/fstab file, which controls drive mappings at startup. We simply add:
# <file system> <mount point> <type> <options> <dump> <pass> tmpfs /dev/shm tmpfs defaults,rw,nodev,nofail,noatime,nosuid,size=2G 0 0
al /etc/fstab proceedings. Do not copy the first comment (# prefix), since it will already be there. At the same time, change the 2G (2GB) according to your calculated requirement / estimated for tmpfs size. It is probably not useful to determine this near or above the size of available memory, as we previously explained.
The header marks on the /etc/fstab file explain the meaning of the fields, and you can find more information in the fstab manual, which can be obtained by writing man fstab. Simply, we ask the operating system to mount a tmpfs File System (system location is in memory, so instead of specifying a device, we indicate tmpfs.) and the type tmpfs, mounted on /dev/shm.
We also establish a series of alternatives. You will probably want to leave the defaults,rw,nodev,nofail minimally (use defaults, read access / writing, no physical device present and do not stop starting the operating system if this mount fails in any way).
You can also choose to leave the optimization alternatives noatime,nosuid If you wish (which is ideal for testing / quality control settings, since it will do it faster while keeping less information about the files in the tmpfs space), or you can delete them (and its matching commas). At the same time, leave (and change / specify size) the size=xG parameter. In summary, we have a standard 0 0 by dump and pass (referee man fstab for more information on these two options).
Once the change is made, just reboot your system and run df -h to verify that you /dev/shm The tmpfs space now has the new size you configured. If something went wrong, just check dmesg (typed at command prompt) and scan up for red error messages (you will likely have to scroll) to find out what went wrong. Even when something went wrong, the system should have started fine anyway, as long as you haven't deleted the nofail option.
For Ubuntu users, exists, despite this, a feasible error nofail pay attention. There used to be an alternative nobootwait option [instead], even though it is not clear if it can still be used and, in that case, in which versions of Ubuntu and its derivatives [only]. As a final alternative to the test, as long as SystemD is being used, you could consider using x-systemd.device-timeout = 10 wait time, where 10 is the number of seconds one is willing to wait throughout the start.
Ending
In this post, we analyze in depth tmpfs sizing, taking into account the use case and other factors.
We also explain tmpfs in detail, figured out how to find the current size of the machine tmpfs File System, and in short looked at how to resize tmpfs.
Enjoy using tmpfs!
