Mount tmpfs in linux
NAME
tmpfs - a virtual memory filesystem
DESCRIPTION
The tmpfs facility allows the creation of filesystems whose contents reside in virtual memory. Since the files on such filesystems typically reside in RAM, file access is extremely fast. The filesystem is automatically created when mounting a filesystem with the type tmpfs via a command such as the following: $ sudo mount -t tmpfs -o size=10M tmpfs /mnt/mytmpfs A tmpfs filesystem has the following properties: • The filesystem can employ swap space when physical memory pressure demands it. • The filesystem consumes only as much physical memory and swap space as is required to store the current contents of the filesystem. • During a remount operation (mount -o remount), the filesystem size can be changed (without losing the existing contents of the filesystem). If a tmpfs filesystem is unmounted, its contents are discarded (lost). Mount options The tmpfs filesystem supports the following mount options: size=bytes Specify an upper limit on the size of the filesystem. The size is given in bytes, and rounded up to entire pages. The size may have a k, m, or g suffix for Ki, Mi, Gi (binary kilo (kibi), binary mega (mebi), and binary giga (gibi)). The size may also have a % suffix to limit this instance to a percentage of physical RAM. The default, when neither size nor nr_blocks is specified, is size=50%. nr_blocks=blocks The same as size, but in blocks of PAGE_CACHE_SIZE. Blocks may be specified with k, m, or g suffixes like size, but not a % suffix. nr_inodes=inodes The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a machine with highmem) the number of lowmem RAM pages, whichever is smaller. Inodes may be specified with k, m, or g suffixes like size, but not a % suffix. mode=mode Set initial permissions of the root directory. gid=gid (since Linux 2.5.7) Set the initial group ID of the root directory. uid=uid (since Linux 2.5.7) Set the initial user ID of the root directory. huge=huge_option (since Linux 4.7.0) Set the huge table memory allocation policy for all files in this instance (if CONFIG_TRANSPARENT_HUGE_PAGECACHE is enabled). The huge_option value is one of the following: never Do not allocate huge pages. This is the default. always Attempt to allocate huge pages every time a new page is needed. within_size Only allocate huge page if it will be fully within i_size. Also respect fadvise(2) and madvise(2) hints advise Only allocate huge pages if requested with fadvise(2) or madvise(2). deny For use in emergencies, to force the huge option off from all mounts. force Force the huge option on for all mounts; useful for testing. mpol=mpol_option (since Linux 2.6.15) Set the NUMA memory allocation policy for all files in this instance (if CONFIG_NUMA is enabled). The mpol_option value is one of the following: default Use the process allocation policy (see set_mempolicy(2)). prefer:node Preferably allocate memory from the given node. bind:nodelist Allocate memory only from nodes in nodelist. interleave Allocate from each node in turn. interleave:nodelist Allocate from each node of in turn. local Preferably allocate memory from the local node. In the above, nodelist is a comma-separated list of decimal numbers and ranges that specify NUMA nodes. A range is a pair of hyphen-separated decimal numbers, the smallest and largest node numbers in the range. For example, mpol=bind:0-3,5,7,9-15.
VERSIONS
The tmpfs facility was added in Linux 2.4, as a successor to the older ramfs facility, which did not provide limit checking or allow for the use of swap space.
NOTES
In order for user-space tools and applications to create tmpfs filesystems, the kernel must be configured with the CONFIG_TMPFS option. The tmpfs filesystem supports extended attributes (see xattr(7)), but user extended attributes are not permitted. An internal shared memory filesystem is used for System V shared memory (shmget(2)) and shared anonymous mappings (mmap(2) with the MAP_SHARED and MAP_ANONYMOUS flags). This filesystem is available regardless of whether the kernel was configured with the CONFIG_TMPFS option. A tmpfs filesystem mounted at /dev/shm is used for the implementation of POSIX shared memory (shm_overview(7)) and POSIX semaphores (sem_overview(7)). The amount of memory consumed by all tmpfs filesystems is shown in the Shmem field of /proc/meminfo and in the shared field displayed by free(1). The tmpfs facility was formerly called shmfs.
SEE ALSO
df(1), du(1), memfd_create(2), mmap(2), set_mempolicy(2), shm_open(3), mount(8) The kernel source files Documentation/filesystems/tmpfs.txt and Documentation/admin-guide/mm/transhuge.rst.
© 2019 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.
Tmpfs¶
Tmpfs is a file system which keeps all of its files in virtual memory.
Everything in tmpfs is temporary in the sense that no files will be created on your hard drive. If you unmount a tmpfs instance, everything stored therein is lost.
tmpfs puts everything into the kernel internal caches and grows and shrinks to accommodate the files it contains and is able to swap unneeded pages out to swap space, if swap was enabled for the tmpfs mount. tmpfs also supports THP.
tmpfs extends ramfs with a few userspace configurable options listed and explained further below, some of which can be reconfigured dynamically on the fly using a remount (‘mount -o remount . ‘) of the filesystem. A tmpfs filesystem can be resized but it cannot be resized to a size below its current usage. tmpfs also supports POSIX ACLs, and extended attributes for the trusted.* and security.* namespaces. ramfs does not use swap and you cannot modify any parameter for a ramfs filesystem. The size limit of a ramfs filesystem is how much memory you have available, and so care must be taken if used so to not run out of memory.
An alternative to tmpfs and ramfs is to use brd to create RAM disks (/dev/ram*), which allows you to simulate a block device disk in physical RAM. To write data you would just then need to create an regular filesystem on top this ramdisk. As with ramfs, brd ramdisks cannot swap. brd ramdisks are also configured in size at initialization and you cannot dynamically resize them. Contrary to brd ramdisks, tmpfs has its own filesystem, it does not rely on the block layer at all.
Since tmpfs lives completely in the page cache and optionally on swap, all tmpfs pages will be shown as «Shmem» in /proc/meminfo and «Shared» in free(1). Notice that these counters also include shared memory (shmem, see ipcs(1)). The most reliable way to get the count is using df(1) and du(1).
tmpfs has the following uses:
- There is always a kernel internal mount which you will not see at all. This is used for shared anonymous mappings and SYSV shared memory. This mount does not depend on CONFIG_TMPFS. If CONFIG_TMPFS is not set, the user visible part of tmpfs is not built. But the internal mechanisms are always present.
- glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for POSIX shared memory (shm_open, shm_unlink). Adding the following line to /etc/fstab should take care of this:
tmpfs /dev/shm tmpfs defaults 0 0
tmpfs has three mount options for sizing:
The limit of allocated bytes for this tmpfs instance. The default is half of your physical RAM without swap. If you oversize your tmpfs instances the machine will deadlock since the OOM handler will not be able to free that memory.
The same as size, but in blocks of PAGE_SIZE.
The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a machine with highmem) the number of lowmem RAM pages, whichever is the lower.
Disables swap. Remounts must respect the original settings. By default swap is enabled.
These parameters accept a suffix k, m or g for kilo, mega and giga and can be changed on remount. The size parameter also accepts a suffix % to limit this tmpfs instance to that percentage of your physical RAM: the default, when neither size nor nr_blocks is specified, is size=50%
If nr_blocks=0 (or size=0), blocks will not be limited in that instance; if nr_inodes=0, inodes will not be limited. It is generally unwise to mount with such options, since it allows any user with write access to use up all the memory on the machine; but enhances the scalability of that instance in a system with many CPUs making intensive use of it.
tmpfs also supports Transparent Huge Pages which requires a kernel configured with CONFIG_TRANSPARENT_HUGEPAGE and with huge supported for your system (has_transparent_hugepage(), which is architecture specific). The mount options for this are:
never: disables huge pages for the mount
always: enables huge pages for the mount
within_size: only allocate huge pages if the page will be fully within i_size, also respect fadvise()/madvise() hints.
advise: only allocate huge pages if requested with fadvise()/madvise()
There is a sysfs file which you can also use to control system wide THP configuration for all tmpfs mounts, the file is:
This sysfs file is placed on top of THP sysfs directory and so is registered by THP code. It is however only used to control all tmpfs mounts with one single knob. Since it controls all tmpfs mounts it should only be used either for emergency or testing purposes. The values you can set for shmem_enabled are:
deny: disables huge on shm_mnt and all mounts, for emergency use
force: enables huge on shm_mnt and all mounts, w/o needing option, for testing
tmpfs has a mount option to set the NUMA memory allocation policy for all files in that instance (if CONFIG_NUMA is enabled) — which can be adjusted on the fly via ‘mount -o remount . ‘
use the process allocation policy (see set_mempolicy(2))
prefers to allocate memory from the given Node
allocates memory only from nodes in NodeList
prefers to allocate from each node in turn
allocates from each node of NodeList in turn
prefers to allocate memory from the local node
NodeList format is a comma-separated list of decimal numbers and ranges, a range being two hyphen-separated decimal numbers, the smallest and largest node numbers in the range. For example, mpol=bind:0-3,5,7,9-15
A memory policy with a valid NodeList will be saved, as specified, for use at file creation time. When a task allocates a file in the file system, the mount option memory policy will be applied with a NodeList, if any, modified by the calling task’s cpuset constraints [See CPUSETS ] and any optional flags, listed below. If the resulting NodeLists is the empty set, the effective memory policy for the file will revert to «default» policy.
NUMA memory allocation policies have optional flags that can be used in conjunction with their modes. These optional flags can be specified when tmpfs is mounted by appending them to the mode before the NodeList. See NUMA Memory Policy for a list of all available memory allocation policy mode flags and their effect on memory policy.
=static is equivalent to MPOL_F_STATIC_NODES =relative is equivalent to MPOL_F_RELATIVE_NODES
For example, mpol=bind=static:NodeList, is the equivalent of an allocation policy of MPOL_BIND | MPOL_F_STATIC_NODES.
Note that trying to mount a tmpfs with an mpol option will fail if the running kernel does not support NUMA; and will fail if its nodelist specifies a node which is not online. If your system relies on that tmpfs being mounted, but from time to time runs a kernel built without NUMA capability (perhaps a safe recovery kernel), or with fewer nodes online, then it is advisable to omit the mpol option from automatic mount options. It can be added later, when the tmpfs is already mounted on MountPoint, by ‘mount -o remount,mpol=Policy:NodeList MountPoint’.
To specify the initial root directory you can use the following mount options:
The permissions as an octal number
These options do not have any effect on remount. You can change these parameters with chmod(1), chown(1) and chgrp(1) on a mounted filesystem.
tmpfs has a mount option to select whether it will wrap at 32- or 64-bit inode numbers:
On a 32-bit kernel, inode32 is implicit, and inode64 is refused at mount time. On a 64-bit kernel, CONFIG_TMPFS_INODE64 sets the default. inode64 avoids the possibility of multiple files with the same inode number on a single device; but risks glibc failing with EOVERFLOW once 33-bit inode numbers are reached — if a long-lived tmpfs is accessed by 32-bit applications so ancient that opening a file larger than 2GiB fails with EINVAL.
So ‘mount -t tmpfs -o size=10G,nr_inodes=10k,mode=700 tmpfs /mytmpfs’ will give you tmpfs instance on /mytmpfs which can allocate 10GB RAM/SWAP in 10240 inodes and it is only accessible by root.
KOSAKI Motohiro, 16 Mar 2010