Talk:tmpfs

Linux Low‑importance

	Linux portal This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.LinuxWikipedia:WikiProject LinuxTemplate:WikiProject LinuxLinux articles
Low	This article has been rated as Low-importance on the project's importance scale.

Computing: Software Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).

Old discussion[edit]

Someone should add th linux 2.4 release/merge date... All other sections contain a merge date....

—Preceding unsigned comment added by 141.84.69.20 (talk) 13:02, 22 February 2008 (UTC)[reply]

duplicate of Tmpfs please merge. --87.162.197.118 23:34, 22 October 2006 (UTC)[reply]

Sorry, Windows temporary files are nothing like tmpfs. This inclusion in the page is silly. The need for a delete on close as a file property is simply due to the silly filesystem architecture of Windows. In Unix systems, you unlink the file from the directory structure while keeping it open. When the last file descriptor referencing that file is closed, then this last close causes the file to be disposed. The Linux tmpfs works fine without swap turned on, in which case there is no place to evacuate the tmpfs pages. Moving tmpfs pages to swap is done the same way like any other virtual memory; it's not a special feature of tmpfs. --192.139.122.66 19:25, 28 February 2007 (UTC)[reply]

The reference ro Ramfs is not appropriate because it redirects to Sysfs (this redirection itself is a very poor choice!), it should be replaced by a reference to RAM_disk. --marc 13:16, 18 April 2007 (UTC)[reply]

This article is completely Linux specific. It should be generalized a bit, or least also give some Solaris examples. Any objections? I believe Net- and FreeBSD are adding support for it as well. (unsigned) 09:59, 26 April 2007

I thought so too, so I did it. Maybe someone else can fill in details for other BSDs, etc. Mditto 21:15, 1 May 2007 (UTC)[reply]

I also switched to a lower case name when referring to tmpfs, which seems to be almost universally preferred, but I haven't yet renamed the page. It seems that the all-caps variant is only used when together with other file system names, perhaps just because it looks funny to have a lower case name next to UFS, VFAT, EXT2... Mditto 21:15, 1 May 2007 (UTC)[reply]

The example shows tmpfs mounted on /dev/shm, not on /tmp at all. han.holl@pobox.com 217.166.18.42 (talk) 11:58, 13 March 2008 (UTC)[reply]

Confusion in lead section[edit]

I recently made this edit to the lead section, which was reverted by an IP user saying "The important feature of TMPFS is being based on virtual memory instead of physical RAM".

Even though in most implementations, tmpfs is tightly coupled to the system's page cache which is considered part of the virtual memory code, you can implement tmpfs, and even paging/swapping, on a computer architecture without virtual memory.

Also note that RAM disk is not Linux's ramfs -- it is a virtual RAM-hosted disk (block device).

So I made this edit; do we both agree on this? -- intgr [talk] 15:19, 9 October 2009 (UTC)[reply]

No, I cannot agree. Memory is either real memory (as in a RAM disk) or virtual as in paging operating systems. Swapping on non virtual memory based systems results in making the whole object unavalable if swapped and does never allow to create a filesystem that is larger than the available system memory. This is not what you like to have in TMPFS. —Preceding unsigned comment added by 195.37.79.236 (talk) 13:44, 13 October 2009 (UTC)[reply]

That's why I used the term "volatile memory" in the latest version — I think we can both agree on this. No matter if virtual or physical memory, it's still volatile.

You seem to be misunderstanding what a RAM disk is. Parts of a RAM disk can just as well be paged out to swap, no different from tmpfs. Virtual memory is not a distinguishing feature of tmpfs.

RAM disk is a virtual disk -- a big blob of preallocated memory implementing a disk interface -- hosting a regular file system (FAT, ext3, whatever).

tmpfs, on the other hand, plugs directly into the VFS layer as a file system itself, and allocates data via regular memory allocation functions. In other words, tmp = temporary or volatile memory, fs = file system in its own right. -- intgr [talk] 17:33, 16 October 2009 (UTC)[reply]

Observations[edit]

Windows tmp files have nothing to do with tmpfs. Systems that use tmpfs have temporary files in a way identical to Windows. The information in the article is wrong. — Preceding unsigned comment added by 97.122.82.116 (talk) 19:14, June 5, 2010 (UTC - 5)

I took the liberty of removing it while cleaning up the Linux section. BioTube (talk) 19:27, 23 July 2011 (UTC)[reply]
I would like to see at least some discussion that tmpfs is either not possible or requires a 3rd party tool to work on Windows. --2600:8800:1300:23D:C481:CC5E:CA64:3398 (talk) 22:34, 26 June 2019 (UTC)[reply]

Dynamically growing[edit]

According to Google RAMFS can grow in size but TMPFS cannot. This contradicts the current article. Can someone who in more knowledgeable check? — Preceding unsigned comment added by 82.152.207.220 (talk) 18:46, 10 September 2011 (UTC)[reply]

Purpose[edit]

Shouldn't the purpose for tmpfs be mentioned somewhere? That it is not for all "temporary files" and that it should be used only for those cases when faster access is needed for those files? That's why it's in RAM and that's why it should be used carefully (particularly with SSDs). — Preceding unsigned comment added by 91.157.74.102 (talk) 07:47, 22 September 2015 (UTC)[reply]