Tmpfs considered harmful • Hacker News Board

Re: Tmpfs considered harmful

#81

Post by saurik » Thu, Sep 13, 2012, 5:30 AM UTC

ta12121 wrote: post #74

regularfry wrote: post #72

Earlier quoted context omitted.

/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.

Re: Tmpfs considered harmful

#82

Post by saurik » Thu, Sep 13, 2012, 5:32 AM UTC

cma wrote: post #80

prodigal_erik wrote: post #53

Earlier quoted context omitted.

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.

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.

Re: Tmpfs considered harmful

#83

Post by regularfry » Thu, Sep 13, 2012, 7:37 AM UTC

ta12121 wrote: post #74

regularfry wrote: post #72

Earlier quoted context omitted.

/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.

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.

Re: Tmpfs considered harmful

#84

Post by tsahyt » Thu, Sep 13, 2012, 8:21 AM UTC

Running out of swap and memory is one thing, although unlikely considering how much of that stuff we've got nowadays. I for instance have 8gb of main memory and 10gb of swap space. 300mb are used after system boot (still too much). That leaves me with plenty of space to "waste" on temporary files in a tmpfs.

The Linux FHS explicitly states "Programs must not assume that any files or directories in /tmp are preserved between invocations of the program." That's not only reboots. It's not meant to be used to store drafts or anything that you might want to reopen at a later time. That's what we've got /var/tmp for. The FHS specifies as follows: "The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp".

Tmpfs isn't harmful because of this, it's the default mutt configuration which is broken. If developers would have adhered to the standard the problem wouldn't exist. Since programs should adhere to the standard, because decisions like the one in question are made upon it, they should be reviewed and their default configurations should be changed in order to fix this issue.

Re: Tmpfs considered harmful

#85

Post by prodigal_erik » Thu, Sep 13, 2012, 4:43 PM UTC

rwallace wrote: post #69

prodigal_erik wrote: post #53

Earlier quoted context omitted.

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…

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