Create mount points on a ramdisk using fstab

Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Locked
Arikania

Create mount points on a ramdisk using fstab

Post by Arikania »

Hello everyone!

I created a ramdisk (tmpfs), and I successfully added it to my /etc/fstab. Now I want to use that single ramdisk, mounted at /mnt/ram/ to mount several file system root folders, such as /proc and /tmp there, but each in its own subdirectory.

One question I have is if it is really necessary to work with subfolders. Can I not simply bindmount all of those folders on the same mount point, resting asure that linux will keep them apart effectively. If the answer is no, then how to I instruct fstab to create the appropriate mount points. And is is possible then to symlink the original /proc's and /tmp's to the corresponding mount points.



Love,
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
fabien85
Level 7
Level 7
Posts: 1877
Joined: Tue Mar 11, 2014 4:30 pm

Re: Create mount points on a ramdisk using fstab

Post by fabien85 »

I cannot answer all of your question, but personally I have put /tmp in RAM by putting the following line in my fstab :

Code: Select all

tmpfs  /tmp  tmpfs  rw,nosuid,nodev,size=512m   0  0
Be careful that anything you mount as tmpfs will we wiped at shutdown, so wont reappear at reboot. It's ok for /tmp, I dont know for /proc (but maybe you know).
Arikania

Re: Create mount points on a ramdisk using fstab

Post by Arikania »

Thank you for your reply.

/proc appears to contain some static data, but mostly it contains numbered directories that are associated with currently running processes. So I figured that I could move those to a ramdisk as well, if only I set the one but last field of the fstab record to 1, meaning that the mounted directory will be dumped to the mount point. Am I right in that assumption?

It seems tricky though for it would require flushing the static part of its content back to the physical disk before rebooting or shutting down, particularly after installing new programs I guess. But for that I could put a script in /etc/init.d that invokes rsync, right?

Another question that remains then is how I get both the /proc and /tmp directory to share the very same ramdisk. I am worried that creating a ramdisk for each and every mount point would result in excessively much redundant memory being claimed.

Perhaps I should resort to a ramfs rather than a tmpfs? tmpfs creates static size disks, whereas the ramfs tends to grow as more space is needed. It would allow me to start out creating a relatively small disk.


Kindly,


UPDATE ON /proc
My / partition has a size of 77 GB. Yet I found a file named kcore in /proc reported to have a size of 140.7 TB?!! Thus I started the computer using a Live USB to run a fsck on it, only to find /proc completely empty. So I guess that it's okay to put that one on a ramdisk as well.
fabien85
Level 7
Level 7
Posts: 1877
Joined: Tue Mar 11, 2014 4:30 pm

Re: Create mount points on a ramdisk using fstab

Post by fabien85 »

Following wikipedia "The memory used by tmpfs grows and shrinks to accommodate the files it contains"
And Arch wiki states that "Note that the actual memory/swap consumption depends on how much you fill it up, as tmpfs partitions do not consume any memory until it is actually needed. "
The defaults maximum size of a tmpfs is half the RAM size, but you can specify a maximum size manually with the mounting option size=something (e.g. in my example above I set the maximum size to 512M).
Thus I think you can perfectly create different tmpfs for different mount points, no need to create a single one and then subdirectories.

I'm still doubtful about /proc, but it's low-level stuff above my paygrade, so I cant say.
I note that the arch wiki says that natural candidates for a tmpfs are /tmp, /var/lock and /var/run

On my computer

Code: Select all

$ ls -lh /proc/kcore 
-r-------- 1 root root 128T Apr 13 12:28 /proc/kcore
but

Code: Select all

$ du -h /proc/kcore 
0	/proc/kcore
so this is a strange file indeed
rene
Level 20
Level 20
Posts: 12240
Joined: Sun Mar 27, 2016 6:58 pm

Re: Create mount points on a ramdisk using fstab

Post by rene »

Please note, /proc is already a RAM-based filesystem, or rather, not even that, but a virtual filesystem where file-content is created by the kernel on the fly when you in fact access a file in /proc. That is, /proc does not contain files as such, has no backing store on actual disk, and has no use for any. The very same is true for /sys by the way.

More explicit still: if a program such as cat reads from, say, /proc/interrupts,

Code: Select all

cat /proc/interrupts
you see current statistics on interrupts, generated on the fly by the kernel in response to the read command(s) that cat gives it, not read from any actual backing store. As such, "moving /proc to a ramdisk" is meaningless. Also note, the kcore file is in similar vein just a file-based view of your (virtual) RAM; 128TB is indeed the normal size on x86_64.

I would by the way also not move /tmp to a ramdisk. /tmp is specified to be a directory that may be severely size-constrained, and volatile over boot, i.e., emptied upon boot or shutdown. It is supposed to sit on the / partition in the sense of said / partition needing to hold enough to fix the system in case of emergency; in practice this means that /tmp is just used for small and short-lived data and should be fine on /.
Arikania

Re: Create mount points on a ramdisk using fstab

Post by Arikania »

Thank you for your replies Fabien. They were quite insightful indeed.

I studied the links, as well as some Googled sites about ramfs vs. tmpfs.

There is indeed no need to create several mount points on a tmpfs, since it is merely accessed via mount points. And most contemporary Linuxes appear to redirect /tmp and /proc to RAM by default. Although, in my noobidity - or is it noobishness - :oops: , I did put these directories on ramfs and the system never complained about it. I will undo this after having completed this reply.

I guess the major considerations of choice are whether I want to limit the maximum amount of that may be consumed by the fs, or that I want to have it "spill over" to swap space instead. In my case, the major goal is to extend the life span of an SD card that holds the system partition.

The ArchWiki link mentions some tmpfs-candidates. Unfortunately is does not mention recommended sizes. I will check the directories mentioned while my Mint is running, and then come with an estimation. But I will make the adjustments for sure, moving /tmp and /proc back where they belong, and tmpfs-ing the subdirs of /var mentioned in your reply and on the wiki's.

You may want to add yet another reply. Otherwise feel free to mark this topic [closed]


Again, with kindest regards and gratitude,
rene
Level 20
Level 20
Posts: 12240
Joined: Sun Mar 27, 2016 6:58 pm

Re: Create mount points on a ramdisk using fstab

Post by rene »

... more explicit still, /proc is not "redirected" to RAM, files in /proc "do not exist".

In the sense of their content being made up by the kernel in response to them being read; said content not being retrieved from disk, hence being incapable of being put on tmpfs. /tmp could be put on tmpfs and some distributions do but note that Mint does not in fact do so by default. Which is as mentioned above something I agree with, but the point is that /proc and /tmp are very different in nature. The latter is (part of) what you would think of as a real filesystem, the former could be called a mere fiction.
Arikania

Re: Create mount points on a ramdisk using fstab

Post by Arikania »

I see. Hence the peculiar file sizes reported in /proc! Yet, risking getting off the topic of this thread, I wonder just what the function of that directory is, and how Linux uses it.

Meanwhile I tried adjusting my fstab by adding:

Code: Select all

tmpfs              /var/lock             tmpfs       defaults,nodev,size=256M          0         1
tmpfs              /var/run              tmpfs       defaults,nodev,size=256M          0         1
But it resulted in my system not wanting to boot anymore :cry: . I guess this is because the first fields of the records are the same? Can I simply invent arbitrary names there? Or should I turn it into something like

Code: Select all

/var/lock           /var/lock             tmpfs       defaults,nodev,size=256M          0         1
/var/run            /var/run              tmpfs       defaults,nodev,size=256M          0         1
This topic is becoming ever more educative for me! Thanks for contributing. :D



With regards,
rene
Level 20
Level 20
Posts: 12240
Joined: Sun Mar 27, 2016 6:58 pm

Re: Create mount points on a ramdisk using fstab

Post by rene »

Arikania wrote:I see. Hence the peculiar file sizes reported in /proc! Yet, risking getting off the topic of this thread, I wonder just what the function of that directory is, and how Linux uses it.
Basically and originally /proc is a communications channel from kernel to userspace, providing information about running processes by said kernel. The for example /proc/1/ directory holds information about process 1, the init process, and you'd on Mint 18.x find said process to be systemd through cat /proc/1/comm. Better, by letting for the purpose created programs do such for you, ps -p 1 -o comm, but those get their information from /proc as well. Over time /proc gained more uses than simple process information but those are being phased out again by moving them to /sys -- although some alternative uses have become ingrained enough that we're probably stuck with them; that /proc/kcore file for example.

Yes, the reported filesize for a file in /proc is normally 0 with (on my system and currently) exceptions only for /proc/kcore and the files in /proc/bus/pci. In both those cases the files are mappings; /proc/kcore of by the kernel maximally addressable memory (hence 128TiB large on current x86_64 systems) and /proc/bus/pci/*/* of PCI configuration space for my PCI/PCIe devices.

Also try man proc and/or man ps for information.
Arikania wrote:Meanwhile I tried adjusting my fstab by adding:

Code: Select all

tmpfs              /var/lock             tmpfs       defaults,nodev,size=256M          0         1
tmpfs              /var/run              tmpfs       defaults,nodev,size=256M          0         1
But it resulted in my system not wanting to boot anymore :cry:
The most direct reason for that was probably the ending 1 on both lines. This causes the boot process to (try to) check the filesystem for consistency before mounting it (man fstab), but certainly here no check utility exists for tmpfs; no /sbin/fsck.tmpfs. That is however not the answer you need. If you on Mint 18.x look at the output of ls -l /var you will find that /var/lock is a symlink to /run/lock and /var/run a symlink to /run itself. From the output of mount or mount -t tmpfs you then find that /run is in fact already a tmpfs; that you needn't move anything; that you're good to go out of the box.
Mute Ant

Re: Create mount points on a ramdisk using fstab

Post by Mute Ant »

A quick mention of an aspect that has only been implied...you are not limited to just one tmpfs mount. You can mount lots of independent RAM disks, from entries in /etc/fstab or with shell commands.

Using entries in /etc/fstab...
tmpfs /tmp tmpfs rw 0 0
tmpfs /root tmpfs rw 0 0
tmpfs /home/mute/.local/share/Trash rw 0 0

Using shell commands...
mount -t tmpfs tmpfs /tmp
mount -t tmpfs tmpfs /root
mount -t tmpfs tmpfs $HOME/.local/share/Trash

Each one will have a 'size' of 50% of the physical RAM unless you specify differently.
Arikania

Re: Create mount points on a ramdisk using fstab

Post by Arikania »

Thank you for your reply, Mute Ant! The ability to create several tmpfs mount points, and in particular by creating them via the command line, is very helpful!

:idea: That greatly improves the flexibility indeed! Now I can make Linux Mint use my external hard disk's /var/www folder only when it is plugged in, and fall back on my SD card if it's not! It gives me the opportunity to create a pretty 404-page in my system partition on the SD, and host my actual website on my hard disk.


With regards,
Locked

Return to “Storage”