Tag Info

Hot answers tagged

16

Linux provides a tmpfs device which any user can use, /dev/shm. It is not mounted to a specific directory by default, but you can still use it as one. Simply create a directory in /dev/shm and then symlink it to wherever you want. You can give the created directory any permissions you choose, so that other users can't access it. This is a RAM backed ...


9

You don't have to do all that, you can just mount /tmp as tmpfs by using a line like the following in /etc/fstab: tmpfs /tmp tmpfs mode=1777,nosuid,nodev 0 0 You can also do it live (but bear in mind stuff that is currently in /tmp on your current filesystem will not be able to be accessed except through the inode and currently open file descriptors, so ...


6

There is no difference betweem tmpfs and shm. tmpfs is the new name for shm. shm stands for SHaredMemory. See: Linux tmpfs. The main reason tmpfs is even used today is this comment in my /etc/fstab on my gentoo box. BTW Chromium won't build with the line missing: # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for # POSIX shared memory ...


6

The data on a tmpfs (Temporary Filesystem) will not persist across reboots. If you only care to preserve the mountpoint, that will be dictated by your /etc/fstab definition.


6

Your system may have one already available; recent Linux systems based on Glibc always have a tmpfs mounted on /dev/shm. If your system doesn't have one or it's too small, then a filesystem not mounted by root pretty much means FUSE. On Ubuntu, you need to be in the fuse group to use FUSE. Looking through available FUSE filesystems, I see only Ramfuse, ...


5

Shared memory is using the 12GB. On your Linux release /dev/shm part of the /dev filesystem (on some releases, it has its own a dedicated file system mounted there). As shown by lsof, the sum is 12 GB: /dev/shm/foo5.44m is 6269616128 bytes /dev/shm/kdfoo.a4o is 6269616128 bytes Neither find nor ls can display theses files because they are unlinked (= ...


5

It's perfectly okay to use some directory in /run as long as you have the appropriate rights on it. In some modern distros, /tmp is already a virtual file system in memory or a symlink to a directory inside /run. If this is your case (you can check that in /etc/fstab, or typing mtab), you could use /tmp as your temporary directory. Also, don't get confused ...


4

use ramfs instead of tmpfs. ramfs is a ramdisk (no swap) tmpfs can be both in your /etc/fstab: none /path/to/location ramfs defaults,size=512M 0 0 edit the size parameter to whatever you like but be careful not to exceed your actual amount of ram. NOTE: the use of a ramfs instead of tmpfs is not something i would recommend. you will find ...


4

If all goes well, your kernel should decide to "do the right thing" all by itself. It uses a lot of fancy heuristics to decide what to swap out and what to keep when there is memory pressure. Those heuristics have been carefully built by really smart people with a lot of experience in memory management and are already good enough that they're pretty hard to ...


4

You didn't specify the filesystem type - this is required. This is what you need: tmpfs /home/rkmax/Projects/webapp/app/cache tmpfs rw,size=500M,nosuid,uid=1000,gid=100 0 0


3

You can resolve which filesystem a directory or file is on with the command df, and if you include the -T option, the output will include the filesystem type. $ df -T /tmp Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/sda3 ext4 38715020 5073600 31674780 14% / In the above example, the /tmp directory is on an ext4 filesystem, ...


3

If you mount a tmpfs instance with a percentage it will take the percent size of the systems physical ram. For instance, if you have 2gb of physical ram and you mount a tmpfs with 50%, your tmpfs will have a size of 1gb. In your scenario, you add physical ram to your system, let's say another 2gb, that your system has 4gb of physical ram. When mounting the ...


3

Imagine you want to bake a cake. You don't know the recipe, but it's okay: you have your cookbook. You take your cookbook out of your locked safe and open it... and here's what you see: sN+zBL0+S/TNORDzFUADrzbv2K5A5zb62o1WPqDA/1vtfiOTVFJnVRaU/++JSjABIBWw7PjHm+cg RnhGFHGv4xy0wTZi5vw8jTiJsgF6pzvOeVaDoiXdHliGFbiCM1rGxyziNesA5RLoLQx5EzGqNzw2 ...


3

tmpfs is implemented as cache pages, so a low value for vm.swappiness will make tmpfs files more likely to be swapped out, since the system will favor stealing cache pages over application pages.


3

The copy will fail prematurely with a file system full situation. In the best case, 4GB of swap and 6GB of RAM will be used to store the original file and the truncated copy. That leaves 10 GB of RAM for the remaining processes, cache and other kernel usage.


2

In general, no, filesystems can only be mounted by root. If you allow a user to place filesystems arbitrarily, that's essentially giving them root. (Easy way: mount one over /etc, put your own passwd and shadow there, su with the new root password you just created, unmount) If you want a tmpfs at a particular location, you could add it to /etc/fstab, with ...


2

tmpfs is not better than the disk cache. So if you want to speed up the Chrome start then you just need to read all the files which Chrome is going to need: cat file1 file2 file2 ... >/dev/null If you find out in which order the files are on the disk then you can optimize the access by reading them in the right order. If you start Chrome afterwards ...


2

Is the device file meaningless in this context? Yes, I think so. I cannot find evidence in the Linux documentation for this, but Googling around did point me at this in the NetBSD documentation about mount_tmpfs to support my thought: The tmpfs parameter only exists for compatibility with the other mount commands and is ignored. So, I guess it ...


2

You're going to need some very specialized hardware to do what you're trying to do. Here are the constraints: The program must be in RAM, because that's where the CPU can find it. It doesn't matter how it got there. The program must not be in RAM unencrypted. I don't know where you want to store the encryption key. Let's assume it's stored in a TPM ...


2

When a program is executed, the necessary code pages are loaded into memory on demand. This is transparent: the kernel loads the pages when it needs them, and tries to be smart by preloading pages that are likely to be needed soon. The code has to be decrypted before it can be executed. If the code is stored on an encrypted filesystem, it is decrypted ...


2

To address the "DirectMap" issue: the kernel has a linear ("direct") mapping of physical memory, separate from the virtual mappings allocated to each user process. The kernel uses the largest possible pages for this mapping to cut down on TLB pressure. DirectMap1G is visible if your CPU supports 1Gb pages (Barcelona onwards; some virtual environments ...


2

The mount command shows what is currently mounted. $ mount|grep -i tmp none on /tmp type tmpfs (rw)


2

On Debian, and likely its derivatives, the script which handles unmounts before halt/reboot is /etc/init.d/umountfs. For me, the script does not umount any of the filesystems you have listed apart from tmpfs. The reason is given in the following comment: # Make sure tmpfs file systems are umounted before turning off # swap, to avoid running out of memory ...


2

cgroup's are meant to control applications, not filesystems. What you're wanting would need to either be a sysctl or a mount option since it's for an entire filesystem. Unfortunately it doesn't look like either of those two features has been created for this problem. That's probably due to how unique an issue like this is. To work around this, you may try ...


2

The 'size' of a tmpfs (like /dev/shm) is only the maximum amount of memory it can use. It doesn't actually use that memory unless its storing something, which in this case it isn't. In short, your /dev/shm isn't actually consuming any memory (well, technically, it's consuming some tiny amount just by existing). It's difficult to give recommendations ...


1

/dev/shm is supposed to by used only by shm_* and sem_* functions implementing the POSIX shared memory and semaphores features. It's been used for quite some time and given its role it makes sense to keep it in memory. /sys/fs/cgroup is more like a virtual filesystem used for cgroups, so again it makes sense to store it in memory, just like /proc. The rest ...


1

There's no difference between shm and tmpfs (actually, tmpfs is only the new name of former shmfs). hugetlbfs is a tmpfs-based filesystem that allocates its space from kernel huge pages and needs some additional configuration afford (how to use this is explained in Documentation/vm/hugetlbpage.txt).


1

You can put these setfacl commands in /etc/init.d/rc.local (if it uses the inittab style init setup) or equivalent in your system.


1

Put # in front of the fstab-Entry, to mark it as a comment. If you look at the script that will trigger the continue-branch within the case-statement, making it skip that line.


1

It's not clear what you're trying to achieve. By default (at least on Debian wheezy), /run/shm is a subdirectory of /run, which is mounted as tmpfs. So if you don't want /run/shm to be a mount point, don't change the default configuration. If you create an entry for /run/shm in /etc/fstab, it will be mounted only if you specify the filesystem type; otherwise ...



Only top voted, non community-wiki answers of a minimum length are eligible