The next steps for swap

Posted Mar 30, 2017 17:45 UTC (Thu) by excors (subscriber, #95769)
In reply to: The next steps for swap by Wol
Parent article: The next steps for swap

Instead of using a filesystem in RAM that gets swapped to disk, wouldn't it be more natural to emerge into a filesystem on disk that gets cached in RAM? In both cases it should ideally store as much as possible in RAM and flush the less-used data to disk, but in the latter case you avoid the ugliness of swapping (the fixed capacity, the performance issues mentioned here, etc).

If the problem is that tmpfs has better performance in practice, why can't the filesystem cache be improved to match that performance?

The next steps for swap

Posted Mar 31, 2017 10:44 UTC (Fri) by lpremoli (guest, #94065) [Link] (1 responses)

IMHO The question is that tmpfs is available since initial boot phase and as such it is a full FS laying on a RAM device (which is available since very initial boot phase). The opposite, i.e. a FS laying on disk and being cached in RAM would be very difficult to implement and would require a disk which is not yet available during early boot.

The next steps for swap

Posted Mar 31, 2017 16:43 UTC (Fri) by Wol (subscriber, #4433) [Link]

Also I don't want stuff left lying around on disk. So caching a memory filesystem in swap makes far more sense then caching a disk filesystem in memory.

Basically, I'm using tmpfs because the data is exactly that - temporary - and a reboot will just dump it. As a desktop system, reboots are common :-)

(And if it's a disk-based filesystem, the chances of data being flushed and then deleted are not negligible, and clearly wasteful :-)

Cheers,
Wol