I wonder if a tmpfs-like filesystem which stores small files into ram, like it does now, and large files to a normal on-disk fs, would work. In a sense tmpfs does that already by using swap, but I guess having a normal on-disk fs would be faster. The on-disk fs could be a simple one, as it doesn't need to be retained over boot.
Posted Jun 1, 2012 12:13 UTC (Fri) by sorpigal (subscriber, #36106)
[Link]
As I read the article I began thinking the same thing. A new tmpfs-like FS that stores all files in RAM at first, stores them on disk if they grow large and also on disk if they remain for a long time. The big question is how you define the on disk location to be used for backing this new tmp; swap seems like a crude solution as (1) I don't use it now and (2) I would prefer to be able have /tmp grow as big as needed without causing the e.g. firefox to get OOMK'd.
Temporary files: RAM or disk?
Posted Jun 3, 2012 6:36 UTC (Sun) by quotemstr (subscriber, #45331)
[Link]
> A new tmpfs-like FS that stores all files in RAM at first, stores them on disk if they grow large and also on disk if they remain for a long time.
You are aware that Linux, like all modern operating system kernels, has a unified caching subsystem, right? The VM subsystem _already does_ exactly what you want: it will page out tmpfs pages to backing storage (in this case, swap) just as it would page out file-backed pages to their backing stores; the exact identity of the backing store doesn't make a difference. The distinction between bytes in memory and bytes on disk isn't nearly as clear-cut as you think.
Temporary files: RAM or disk?
Posted Jun 4, 2012 5:08 UTC (Mon) by raven667 (subscriber, #5198)
[Link]
One of the few reasonable statements in this discussion... Using the robust features of the kernel to implement the most sensible policy, who would have thought.