User: Password:
|
|
Subscribe / Log in / New account

Temporary files: RAM or disk?

Temporary files: RAM or disk?

Posted Jun 9, 2012 16:36 UTC (Sat) by Serge (guest, #84957)
In reply to: Temporary files: RAM or disk? by iq-0
Parent article: Temporary files: RAM or disk?

> The only thing missing is an option that you could claim a swap space as designated for only allowing tmpfs spillover.

You have this option — use a separate ext3 partition. :)

> we do often generate lots of temporary files (for sorting or graphing) and some might actually be rather large.

Why do you use tmpfs then? You can just use regular disk. Have you noticed some speedup because of using tmpfs?

> Tmpfs really is the most sane option for /tmp. Why bother doing cleanups at boot?

Why bother about tmpfs size? Why bother about adding more swap. Why bother about system slowed down because of heavy swap usage? On-disk /tmp don't have these problems. And it's cleaned on boot automatically anyway, no need to bother.

> Why bother guaranteeing on disk-consistency or doing disk flushes on sync/fsync/fdatasync.

Nobody does fsync in /tmp, so nobody bothers. :)

> The only sane alternative would be a ext2 filesystem with all data guarantees turned off and recreating it every time you boot.

That's why ext3 is better. Replaying ext3 journal is faster than creating a new filesystem.


(Log in to post comments)

Temporary files: RAM or disk?

Posted Jun 14, 2012 9:05 UTC (Thu) by iq-0 (subscriber, #36655) [Link]

> You have this option — use a separate ext3 partition. :)

The problem with disk based /tmp is not that tmpfs or ext3 is faster perse. It's about when they want to do I/O:
- Ext3 sooner or later wants to write all data to disk, this might be because of dirty memory limits or because some application does a sync like call or sync on rename. But it *wants* to be on a disk.
- Tmpfs has no desire to be on disk. Sure, if the system is under memory pressure it is a candidate to being written to disk, but that's about the only case that it ever happens. And any data that is written to disk doesn't need the indexing on disk to retrieve it, just the in-memory indexing which is volatile, just as you expect from a temporary filesystem.

And you can tune a lot about ext3, but at it's core it wants to make sure an always valid structure on disk exists. You can't make it ignore any sync requests, you can't tell it to not bother updating the free-space (you want it to be empty each time it's mounted, so why bother keeping track of which blocks are free?).

> Why do you use tmpfs then? You can just use regular disk. Have you noticed some speedup because of using tmpfs?

I don't know about you, but disk I/O is one of the biggest bottlenecks on our systems. And trying to prevent any for of I/O unless really necessary really helps overall system performance. So yes, we do.

> Nobody does fsync in /tmp, so nobody bothers. :)

Oh? Most software is oblivious to where they write or how their writes might affect performance. And often software is rightfully written to be "correct" (power fail safe) but are in some cases used in a different capacity than was originally imagined. And some tools call 'sync' (like "dpkg" and probably "rpm" too), which sync *all* filesystems mounted.

> That's why ext3 is better. Replaying ext3 journal is faster than creating a new filesystem.

You know what is faster than replaying a journal and than performing (effectively) 'rm -rf' on it? Never creating a filesystem in the first place. Swap space never has to be recreated it's assumed to be unused on fresh boot.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds