Someone should add th linux 2.4 release/merge date... All other sections contain a merge date....
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. --22.214.171.124 19:25, 28 February 2007 (UTC)
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)
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)
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)
Confusion in lead section
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.
- 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 126.96.36.199 (talk) 13:44, 13 October 2009 (UTC)
- 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)
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 188.8.131.52 (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)
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 184.108.40.206 (talk) 18:46, 10 September 2011 (UTC)
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 220.127.116.11 (talk) 07:47, 22 September 2015 (UTC)