As you know, the access speed of a memory is very important. The bottlenecks generated in the past between magnetic memories and processors meant that a faster buffer memory had to be included, RAM. Later, with the advancement of microprocessors came the cache, even faster to offer a buffer between the RAM and the CPU registers. More recently SSD hard drives have appeared, which are faster than magnetic-mechanical HDDs as they are based on flash memory.
Gigabyte thought a few years ago to create a hard drive with RAM (a RAMDisk called i-RAM), a very fast memory compared to hard drives, but something similar happened to what happened to Ageia with its PhysX card. They didn't really gel and ended up disappearing from the market, and now with SSDs (and RAM-based SSDs) it makes even less sense. What is it about? Well, it is basically using RAM memory to store data as if it were a hard disk, so access is much faster.
Well, you don't need an i-RAM or an SSD, or anything like that to speed up transfers and access to the directories, files or programs you want. For that you can create a RAMDisk on your Linux distro. The only requirement is to have enough RAM,> 4GB recommended, to reserve a bit of it to use as an ultra-fast "hard disk". Something like what some GPUs for laptops did with Share Memory, but in this case for your data.
To create this memory, you must calculate the memory you have, since if you exhaust all or a large part of it you will run out of RAM for the purposes for which it was created and it will be stupid. For example, if you have 8GB of RAM, you could take 2GB for the RAMDisk. I repeat, his thing is that you have more RAM, if you have 2GB or 4GB it may not be worth it ... (remember in "size =" specify the size, in my example I have opted for 1024MB, that is, 1GB, or you can also use "G" instead of "M" to specify it in GB) Once you know this, we get to work with the following steps from your terminal:
mkdir /tmp/ramdisk mount -t tmpfs none /tmp/randisk -o size=1024M
Now you have 1GB reserved in your RAM so you can add whatever you want to the ramdisk directory that we have created. Do performance tests and you will see how it is faster everything you have in it ... If you want, you can create the partition in your RAM with another file system other than tmpfs, such as ext4 or ramfs.
And if you want the montage input to remain… Be careful !! The data that you save here if you turn off the PC or restart will be lost, but the input will remain pso that you don't have to create the partition with every startup with the following trick to add it to the partition table (fstab) so that it is created automatically (use your favorite text editor to edit the input: vi, nano, gedit ...):
gedit /etc/fstab Y en el fichero de texto que se abre crea la siguiente entrada sin comillas "tmpfs /mnt/ramdisk tmpfs nodev, nosuid, noexec, nodiratime, size=1024M 0 0"
IMPORTANT: Remember that your data will disappear when you restart or shut down computer, since RAM is volatile memory. So whatever you want to keep, make a copy of it on a partition on your hard drive.
I have a question, once we turn off the equipment, will the data continue to be in memory? I say this since RAM is volatile. I would appreciate if you could explain that to me.
Hello,
You're right, I forgot to comment in the article that being volatile it will be deleted every time you start the computer. Thanks for reminding me, I've already added it. It is something very important that should not be overlooked so that no one loses their data.
Cheers and hope I helped. Thanks!!!
What I was seeing is that there are programs that do this partition. What these programs do is create an image on the hard disk of the data that is in RAM so that when we restart they are not lost. Then when starting the system, as I understand it, the data saved on the hard disk is dumped into RAM so that we can use it again. Thanks for the note and for having responded quickly! Greetings!
Interesting, it is worth thinking about some practical applications, a script that creates this RAM partition at the beginning and loads files of interest, it will not be useful ... to put a database ...? you have to investigate the subject ... thanks for the note.
it may only work detailing the fs. In my tests it has only worked as follows:
mount -t tmpfs tmpfs / tmp / ramdisk -o size = 300m
Incredible, the magnificences that can be done with GNU / LINUX. :)
How about we use that RAMDisk for the "tmp" partition?
Of being able, I could, it will be necessary to put code, I do not ask for the code I ASK ABOUT THE PRACTICALITY OF THE SUBJECT, TO USE IT. I note that for databases, although I remember correctly, there is already an option to support database tables in RAM memory, example: https: // dev.mysql.com/doc /refman/5.5/en/ storage-engine -setting.html
If you are lucky and dragged during the last 20 years you will be able to have 64GiB of RAM and thus be able to copy the virtual hard disk file of VirtualBOX (or any other virtual machine) to RAM; I assume that this file does not occupy more than 48GiB (to leave enough free RAM for Linux and for the virtual machine). In this way the virtual machine flies, and if you also want the changes in the virtual machine to be lost (immutability) you will no longer need to lose performance in making the virtual hard disk of the machine immutable, because before starting it you copy it from the NVMe / SSD / HDD to RAM and then turning off whatever is in RAM is lost (just what is desired in this case, which is immutability).
So, with so much RAM you can make the image of the hard disk not immutable and of fixed size, obtaining the maximum possible performance in the access, that together with the fact that said hard disk will be in the RAM, it makes some real delights when handling virtual machines (only one snatch at a time).
That when you finish using the virtual machine, you want to preserve the state of the virtual hard disk, since it is copied from the RAM to the NVMe / SSD / HDD.
That I have seen there are already some NVMe that are capable of reading at speeds a little over 5GiB / s (yes, five gigabytes per second in reading) and that using only one (in RAID0 or similar would be even faster), for copying the 48GiB virtual hard disk image from it to RAM takes only about ten seconds, olé!
By cons when doing the opposite process (from RAM to NVMe) the fastest I've seen for now are a little more than 3GiB / s in writing (yes, three gigabytes per second in writing), so saving the image of 48GiB virtual hard drive from RAM to NVMe takes only about eighteen seconds, again a huge olé!
We are going to have one of the fastest NVMe and 64GiB of RAM with Linux and a virtual machine with for example Windows 10, it is quite a pass if the RAM is used to host the hard disk of the virtual machine.
And now the gift for Linux ... there is already a package called "ramroot" (at least it seems that for Arch-based distributions) that during startup is responsible for copying the entire root of the Linux system to RAM and continuing to boot from RAM , with which we also obtain immutability on the Linux that we are using, not to mention that it will run from RAM, at the cost of increasing the boot time somewhat.
If whoever reads this knows the Linux distros bootable from CD / USB that are copied to RAM during startup (such as SystemRescueCD, etc), they will know the benefits it provides: It always starts the same, it always goes as fast as it can because everything is in RAM, nothing is written to the physical disks during startup or while using Linux (something very useful to extend the life of the SSD, personally in less than a month and with less than a terabyte written, some SSDs have already left me to work, specifically 120GB of the KingDian brand), except obviously if we mount something in read & write and save something there, combining this with the virtual machine, the system 'flies' in disk accesses, since everyone goes to the RAM.
Having all the Linux in RAM greatly lengthens the useful life of the SSD and NVMe, since nothing or almost nothing is written to them during boot and once started absolutely nothing unless we are the ones who do it.
My tests have been on a Ryzen 7 2700X (4.35GHz with 8 cores and 16 threads) with 64GiB DDR4 3200MHz and 1050GiB NVidia 4 Ti Graphics.
Note: There are motherboards that even support 1TiB of RAM and 64-thread mics like the ThreadRipper 2, etc.
Your comment is very interesting, but we should not exaggerate with the necessary RAM: I have a VDI image of Windows 10 that weighs only 13 GB, with 14 GB of RAM it would work with total ease.
I am not very clear about mounting the entire OS in RAM that it is not a bit too much. If you have your SSD formatted in BTRFS with on-the-fly compression enabled (considerably less data is written to the drive), since almost only data is written to the system partition when packages are installed (which we obviously want to stay in the SSD / disk), configuration files are modified (text files of negligible size, and the LZO compression of BTRFS leaves them in an even more negligible size) and little else, because it seems to me to kill flies with cannon shots; keep in mind that all modern distros motan / tmp in RAM if the user has more than 4 GB, I think of RAM, so the SSD / disk does not suffer the least wear due to many temporary operations that are written, which was what more cane I put in the / partition a few years ago.
Another thing is the home, there data is constantly written: caches, settings that change every so often if we have moved a window, downloads, etc. There it could be interesting to work only in RAM and synchronize to disk only if we really want, although there should be some tool (I don't know if there will be, I would not be surprised, but until reading your comment I have not thought about the subject ) to remind the user when they are going to close the session that there are changes in their / home without saving or even ask us if we want to synchronize them to disk, because surely half the time we would forget and we would turn off the computer to help ourselves in the lead half a second later.
"There are motherboards that even support 1TiB of RAM and microphones with 64 threads like the ThreadRipper 2, etc."
Already, and racks that still support much more, but don't let us go xD. Let's go back to planet Earth where people can hardly afford a € 800 team ...
Greetings.
"I have a VDI image of Windows 10 that weighs only 13 GB, with 14 GB of RAM it would work with total ease."
Sorry, I meant 24GB. Did my finger go to the next key?