|  | .. SPDX-License-Identifier: GPL-2.0 | 
|  |  | 
|  | ===== | 
|  | 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.*, security.* and user.* 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: | 
|  |  | 
|  | 1) 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. | 
|  |  | 
|  | 2) 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 | 
|  |  | 
|  | Remember to create the directory that you intend to mount tmpfs on | 
|  | if necessary. | 
|  |  | 
|  | This mount is _not_ needed for SYSV shared memory. The internal | 
|  | mount is used for that. (In the 2.3 kernel versions it was | 
|  | necessary to mount the predecessor of tmpfs (shm fs) to use SYSV | 
|  | shared memory.) | 
|  |  | 
|  | 3) Some people (including me) find it very convenient to mount it | 
|  | e.g. on /tmp and /var/tmp and have a big swap partition. And now | 
|  | loop mounts of tmpfs files do work, so mkinitrd shipped by most | 
|  | distributions should succeed with a tmpfs /tmp. | 
|  |  | 
|  | 4) And probably a lot more I do not know about :-) | 
|  |  | 
|  |  | 
|  | tmpfs has three mount options for sizing: | 
|  |  | 
|  | =========  ============================================================ | 
|  | size       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. | 
|  | nr_blocks  The same as size, but in blocks of PAGE_SIZE. | 
|  | nr_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 the lower. | 
|  | =========  ============================================================ | 
|  |  | 
|  | 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. | 
|  |  | 
|  | If nr_inodes is not 0, that limited space for inodes is also used up by | 
|  | extended attributes: "df -i"'s IUsed and IUse% increase, IFree decreases. | 
|  |  | 
|  | tmpfs blocks may be swapped out, when there is a shortage of memory. | 
|  | tmpfs has a mount option to disable its use of swap: | 
|  |  | 
|  | ======  =========================================================== | 
|  | noswap  Disables swap. Remounts must respect the original settings. | 
|  | By default swap is enabled. | 
|  | ======  =========================================================== | 
|  |  | 
|  | 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: | 
|  |  | 
|  | ================ ============================================================== | 
|  | huge=never       Do not allocate huge pages.  This is the default. | 
|  | huge=always      Attempt to allocate huge page every time a new page is needed. | 
|  | huge=within_size Only allocate huge page if it will be fully within i_size. | 
|  | Also respect madvise(2) hints. | 
|  | huge=advise      Only allocate huge page if requested with madvise(2). | 
|  | ================ ============================================================== | 
|  |  | 
|  | See also Documentation/admin-guide/mm/transhuge.rst, which describes the | 
|  | sysfs file /sys/kernel/mm/transparent_hugepage/shmem_enabled: which can | 
|  | be used to deny huge pages on all tmpfs mounts in an emergency, or to | 
|  | force huge pages on all tmpfs mounts for testing. | 
|  |  | 
|  | tmpfs also supports quota with the following mount options | 
|  |  | 
|  | ======================== ================================================= | 
|  | quota                    User and group quota accounting and enforcement | 
|  | is enabled on the mount. Tmpfs is using hidden | 
|  | system quota files that are initialized on mount. | 
|  | usrquota                 User quota accounting and enforcement is enabled | 
|  | on the mount. | 
|  | grpquota                 Group quota accounting and enforcement is enabled | 
|  | on the mount. | 
|  | usrquota_block_hardlimit Set global user quota block hard limit. | 
|  | usrquota_inode_hardlimit Set global user quota inode hard limit. | 
|  | grpquota_block_hardlimit Set global group quota block hard limit. | 
|  | grpquota_inode_hardlimit Set global group quota inode hard limit. | 
|  | ======================== ================================================= | 
|  |  | 
|  | None of the quota related mount options can be set or changed on remount. | 
|  |  | 
|  | Quota limit parameters accept a suffix k, m or g for kilo, mega and giga | 
|  | and can't be changed on remount. Default global quota limits are taking | 
|  | effect for any and all user/group/project except root the first time the | 
|  | quota entry for user/group/project id is being accessed - typically the | 
|  | first time an inode with a particular id ownership is being created after | 
|  | the mount. In other words, instead of the limits being initialized to zero, | 
|  | they are initialized with the particular value provided with these mount | 
|  | options. The limits can be changed for any user/group id at any time as they | 
|  | normally can be. | 
|  |  | 
|  | Note that tmpfs quotas do not support user namespaces so no uid/gid | 
|  | translation is done if quotas are enabled inside user namespaces. | 
|  |  | 
|  | 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 ...' | 
|  |  | 
|  | ======================== ============================================== | 
|  | mpol=default             use the process allocation policy | 
|  | (see set_mempolicy(2)) | 
|  | mpol=prefer:Node         prefers to allocate memory from the given Node | 
|  | mpol=bind:NodeList       allocates memory only from nodes in NodeList | 
|  | mpol=interleave          prefers to allocate from each node in turn | 
|  | mpol=interleave:NodeList allocates from each node of NodeList in turn | 
|  | mpol=local		 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 Documentation/admin-guide/cgroup-v1/cpusets.rst] 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 Documentation/admin-guide/mm/numa_memory_policy.rst 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: | 
|  |  | 
|  | ====	================================== | 
|  | mode	The permissions as an octal number | 
|  | uid	The user id | 
|  | gid	The group id | 
|  | ====	================================== | 
|  |  | 
|  | 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: | 
|  |  | 
|  | =======   ======================== | 
|  | inode64   Use 64-bit inode numbers | 
|  | inode32   Use 32-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. | 
|  |  | 
|  | tmpfs has the following mounting options for case-insensitive lookup support: | 
|  |  | 
|  | ================= ============================================================== | 
|  | casefold          Enable casefold support at this mount point using the given | 
|  | argument as the encoding standard. Currently only UTF-8 | 
|  | encodings are supported. If no argument is used, it will load | 
|  | the latest UTF-8 encoding available. | 
|  | strict_encoding   Enable strict encoding at this mount point (disabled by | 
|  | default). In this mode, the filesystem refuses to create file | 
|  | and directory with names containing invalid UTF-8 characters. | 
|  | ================= ============================================================== | 
|  |  | 
|  | This option doesn't render the entire filesystem case-insensitive. One needs to | 
|  | still set the casefold flag per directory, by flipping the +F attribute in an | 
|  | empty directory. Nevertheless, new directories will inherit the attribute. The | 
|  | mountpoint itself cannot be made case-insensitive. | 
|  |  | 
|  | Example:: | 
|  |  | 
|  | $ mount -t tmpfs -o casefold=utf8-12.1.0,strict_encoding fs_name /mytmpfs | 
|  | $ mount -t tmpfs -o casefold fs_name /mytmpfs | 
|  |  | 
|  |  | 
|  | :Author: | 
|  | Christoph Rohland <cr@sap.com>, 1.12.01 | 
|  | :Updated: | 
|  | Hugh Dickins, 4 June 2007 | 
|  | :Updated: | 
|  | KOSAKI Motohiro, 16 Mar 2010 | 
|  | :Updated: | 
|  | Chris Down, 13 July 2020 | 
|  | :Updated: | 
|  | André Almeida, 23 Aug 2024 |