Tmpfs considered harmful • Hacker News Board

Re: Tmpfs considered harmful

#51

Post by jaylevitt » Wed, Sep 12, 2012, 3:08 PM UTC

praptak wrote: post #4

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.

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?)

Re: Tmpfs considered harmful

#52

Post by scotty79 » Wed, Sep 12, 2012, 4:12 PM UTC

tmpfs is awesome to run rails from (i.e. for development).

IO bound becomes CPU bound so you're getting as good speed as you can get.

Re: Tmpfs considered harmful

#53

Post by prodigal_erik » Wed, Sep 12, 2012, 4:22 PM UTC

saurik wrote: post #41

rwmj wrote: post #25

Earlier quoted context omitted.

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.

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.

Re: Tmpfs considered harmful

#54

Post by aidenn0 » Wed, Sep 12, 2012, 4:43 PM UTC

dmpk2k wrote: post #15

One of the hardest parts of writing a compiler is register allocation. Not quite. There are many much more difficult problems in a competitive optimizing compiler before hitting that step. You can get reasonable results from even a linear scan allocator, which is simple.

It really depends on the architecture. There are some architectures with only 1 register, and others with many thousands of registers.

Current x86 implementations do a good job of being fast even when registers spill.

I've seen dual-issue Power cores (32ish registers) that only have 16k of 4-way dcache, which means register spills can easily kill performance.

Re: Tmpfs considered harmful

#55

Post by spartango » Wed, Sep 12, 2012, 4:48 PM UTC

I'd disagree with the more global point (in the title) that tmpfs is harmful: it's actually quite handy for all sorts of things.

As an amusing example, the SHM (shared memory) system in linux is actually implemented on top of tmpfs (/dev/shm is a tmpfs mount).

Other uses include CoW shadow mounting (when unioned to an immutable filesystem).

That said, the point that /tmp should not be a tmpfs mount is actually a decent one, just because we're used to the idea that /tmp is neither space-constrained (it's scratch space) nor extra performant.

Re: Tmpfs considered harmful

#56

Post by krakensden » Wed, Sep 12, 2012, 5:46 PM UTC

I'm surprised no one is chanting "CADT" and linking to "What killed Linux on the desktop". This sort of subtle breakage over time is absolutely goddamn maddening.

Re: Tmpfs considered harmful

#57

Post by notatoad » Wed, Sep 12, 2012, 6:03 PM UTC

Why on earth would anybody ever use tmpfs for /tmp? If I'm writing a program that deals with a big file, and I want to temporarily write something to the filesystem, it is because I dont want it in memory. Why would you ever write to /tmp for any reason other than to get something out of ram for a while?

Re: Tmpfs considered harmful

#58

Post by notatoad » Wed, Sep 12, 2012, 6:06 PM UTC

raverbashing wrote: post #7

"Everyone must now be careful never to store a file in /tmp that might grow large" If you're going to trash my /tmp with gigantic files please don't. Really "it’s better to fix the filesystem to make it faster" Yes, let's spend adding more complexity to the file system to work out every /tmp abuser out there. But his original point was avoiding adding complexity in the first place So basically, he contradicts himself…

The /tmp on your system is not 'your' /tmp. The home directory is yours. /tmp exists pretty much solely as a place for programs to fill up with a mess of files, with the understanding that it will get automatically cleaned out and they aren't messing up the system proper. If a program needs to trash a place with large files, /tmp is where it should do it.

Re: Tmpfs considered harmful

#59

Post by donavanm » Wed, Sep 12, 2012, 6:19 PM UTC

notatoad wrote: post #57

Why on earth would anybody ever use tmpfs for /tmp? If I'm writing a program that deals with a big file, and I want to temporarily write something to the filesystem, it is because I dont want it in memory. Why would you ever write to /tmp for any reason other than to get something out of ram for a while?

Because a third party binary expects posix FS semantics for some data that does not require strong durability?

Re: Tmpfs considered harmful

#60

Post by chimeracoder » Wed, Sep 12, 2012, 6:20 PM UTC

notatoad wrote: post #57

Why on earth would anybody ever use tmpfs for /tmp? If I'm writing a program that deals with a big file, and I want to temporarily write something to the filesystem, it is because I dont want it in memory. Why would you ever write to /tmp for any reason other than to get something out of ram for a while?

I use /tmp all the time. I find myself needing to interact with things for which the filesystem/shell interface is appropriate, but for which I don't want to worry about having to clean out the directory before it gets too large.

Having it sit in RAM is great, because I get the speed without subjecting my disk to unnecessary writes - for certain operations, this can be a huge bonus.