Hacker News Reader

Comment by praptak | Hacker News Reader

Minor disagreement about the following: "Everyone must worry about whether their files need to survive a reboot"

I believe there was never such expectation of /tmp. On many systems it's being wiped periodically or even when the user's last session ends. The example app(s) that use /tmp for drafts need(s) to be fixed.

View on HN

Totally agree, /tmp should be wiped at the end of each session.

Agreed; this prevents establishment of expectations otherwise.

Also prevents it filling up your disk.

The key is that it may be wiped. Files stored in /tmp are not guaranteed to survive boot. Whether or not they are there or not is a bit of a gamble (a regularly losing one should you choose tmpfs).

This is exactly what I use it for on my desktop. I have any app that I don't want to maintain longterm history for it's internal files (ex: Firefox browser cache) pointed to /tmp (mounted as tmpfs). As an added bonus if you're running your OS on an SSD (which you should be) you don't have it thrashed by constant writes/deletes.

The memory size issue is basically a non-issue at this point (pair of desktop 16 GB DIMMS are ~$80 and laptop isn't that much more).

The memory size issue is very much still an issue. I happen to have globs of memory on my machine, but for the very reason that I have software to use it. If large tmp files start eating into the resources available to my programs, its an issue for me. Also, older hardware that has less memory available, and even newer hardware that can have more memory installed but with non-tech users who don't know how to upgrade it or even that its possible (or can't afford $80).

If it's an issue for you, you can simply umount the tmpfs and remove the entry for fstab. I think this is a good default - on all mystems these days, it's disk-io that's the killer, not running out of memory.

Surely thats what /var/tmp is intended for.

By "that" you probably mean "temporary files preserved between reboots". I agree :)

The Linux FHS agrees too, that this should be the distinction between /tmp and /var/tmp.

I can verify this - on my Fedora 12 box, I accidentally set up a test MySQL database into /tmp. The test database grew into my blog, and it worked great till I rebooted. Then I learned lots about recovering data. (I make regular backups, of coures, but who backs up /tmp?)

Sure, but if the power goes down, there's at least a chance that I may be able to find that long email I was writing. With /tmp on tmpfs, it's gone.

That's why the GP considers mutt broken. Drafts should be stored in ~/.mutt or /var, not /tmp. Files in /tmp should not be expected to survive a process.

This is exactly the point of the posting. Every program has to be examined for this problem, and it forces a complex decision about the storage hierarchy onto every programmer.

Do you consider distros that rm -rf /tmp on startup to be broken? If not, why not?

Firstly Fedora (<= 17) doesn't do this. It has a tmpwatch cronjob which deletes files after 10 days (/tmp) and 30 days (/var/tmp).

Secondly, no I don't think it's broken. But it doesn't in any way affect the fact that as a last resort I can reboot in single user mode and grab the precious mutt file before it gets deleted.

That's like saying "RAM considered harmful", because every time a developer has to think "do I just store this in memory, or do I sync it to disk" "it forces a complex decision about the storage hierarchy": /tmp is simply RAM that has the API of a file; it used to be implemented using a horrible kludge with files on disk that were periodically deleted, but with tmpfs the dream became a reality.

RAM really is a harmful kludge. Neither Turing machines nor lambda calculus call for some of an algorithm's state to suddenly be obliterated. The only reason we put up with it is that disk and SSD are so much slower.

Speed is not the only benefit of RAM. The internal data structures of most programs are gnarly messes of intertwined pointers, fragile, easily corrupted, hard to upgrade in place, almost impossible to fix when they break. The division between RAM and disk forces everything to be serialized at intervals to clean storage formats that can be reread for a fresh start. As a practical matter, that's a big enough benefit to justify enforcing the division at an API level even if disk were as fast as RAM.

The industry might produce less worthless crap without the crutch of "it's not quite unusable if you start over often enough".

I've never understood the obsession with Turing machines. It's like basing one's core belief of what a car is off one of Da Vinci's crazy wind-up things.

Ram is just state. Turing machines require a non-tape state machine mechanism. You could consider ram a part of that, 4 gigs corresponding to many many possible states.

Some people (I do not agree with this view) believe that applications should be universally persistent: so that they never "stop running" and never "lose data" even when the machine restarts or even if the programs are transferred between systems.

    /tmp is simply RAM that has the API of a file

...which used to behave, physically, as disk, and now behaves as RAM. If I'm doing large file manipulations that require temporary files larger than RAM where should I put them?

/tmp. If it's tmpfs, it can expand into swap space.

Swap is usually no bigger than two or three times your RAM. Disk in general is 10 to 100 times the size of your RAM.

You should take all of the space you previously felt acceptable to provide /tmp and allocate it to swap space. The history and semantics of that folder and how it relates to RAM, especially on systems that could not implement swap space, actually make this make sense: if you upgrade to tmpfs from "periodic deletion of /tmp" and are not increasing the size of your swap partition accordingly, you are doing something wrong.

If you know you're going to need more space, you can just create a transient swapfile for the duration. Or use /var/cache, if you suspect you know better than tmpfs and the swap allocator.

According to the comments on the original article, that location is /var/tmp. Apparently it's some sort of convention/standard.

First time I've heard about /var/tmp.

Every program has to be examined for this problem anyway, tempfs or otherwise, so I don't get the point.

Every program has had to be designed with this in mind for decades or be broken on any number of systems. This may be new behaviour for Fedora, but it's not a new thing on Linux, or for Unix-like systems in general.

It's not just systems that delete on reboot, but also systems set up with cron-jobs to regularly wipe /tmp, or sysadmins that will (rightfully) see /tmp as something that can be wiped at pretty much time.

I'd vote for ~/.cache

I can't help but find that to be an issue of the MUA rather than that of the filesystem.

Although I agree with your points, I find that the design of one application alone cannot be a justifiable point.

No, because /tmp is supposed to be assumed to be cleared on start up. If you want something to survive between reboots, /tmp is the last place you should put it, even if you're not using tmpfs.

I've never had a problem with this using mutt, but if I cared, I'd switch it to use /var/tmp.

Either way, if there's a problem, it's with the program, not the filesystem - no need to use a cannon to kill a fly.

I remember myself creating cron jobs to free wasted /tmp space

Reply on news.ycombinator.com