Hacker News Reader

Comment by o11c | Hacker News Reader

/tmp on tmpfs is fine.

/var/tmp being cleaned on boot is probably fine despite contrary standards in the past.

But automatically deleting files - in either of those - while the system is running is going to break all sorts of things.

As a random example, `chromium --temp-profile` will have half the profile deleted (since some particular files aren't accessed frequently) while the browser is running. This looks designed to cause system-level UB.

Note that locks on directories are pretty rare; locks on a file within the directory are the de facto standard, on the assumption that only cooperating programs will access them.

View on HN

/tmp on tmpfs is fine.

Hanging my comment here. Sorry to slap it into your universe.

My knowledge says... is it fine?

My RAM is for applications, and I buy RAM accordingly.

Most in this discussion seem to miss something quite vital and important. Linux is excellent at caching most-needed, most-used data in RAM, eg buff/cache in 'top', and that should be given higher priority than some temporary file a user might slap in /tmp/.

50% of my RAM, randomly flushing out buffers and cache! Buffers and cache, which stores commands I use frequently, libraries often used by applications, and so on! Any server that is reasonably loaded, will show RAM fully used by buffers/cache, excluding active RAM requirements. Now I'm to give 50% of this up, having those buffers/cache flushed for... someone unarchiving a tarball?!

And my swap file, something for emergency application RAM usage, now being stolen by /tmp. We're basically taking the most expensive storage space on a system, RAM, and relegating it to... a few log files, someone untarring software, and also...

Hard limiting its size to RAM requirements?!

This is sheer madness. It smacks of people with desktops, with enormous amounts of free RAM, making decisions for servers.

This change is bad.

Thoughts:

* It is not relevant what systemd does, endless things in Debian and other distros diverge from what systemd does

* Debian isn't aligning with 'other distros' when doing this, as there isn't a consensus here. Debian isn't some hold out, in fact there are far, far fewer installs elsewhere doing this.

* Stealing my RAM for transient files is dumb

> Now I'm to give 50% of this up, having those buffers/cache flushed for... someone unarchiving a tarball?!

Nope, unarchiving tarballs doesn't write the tarball content to /tmp.

> It smacks of people with desktops, with enormous amounts of free RAM, making decisions for servers.

* Servers usually have way more RAM than desktop devices? Unless you mean VMs, in which case the VM can't decide what device /tmp lies in anyway.

* in any case it will be trivial to just not use it for your servers, if you prefer /tmp to be on disk. Just like I already used tmpfs for 2 decades in Debian, it is a single line in /etc/fstab either way.

Eh? Yes, if I untar a file in /tmp, it will go there.

My whole post talks about putting files in tmp!

And this change is a performance killer for that reason. Taking all that juicy, super fast RAM away from system caches and buffers, which yes is a performance killer.

You want sensible defaults. Telling people they can change a dumb default to something smart, isn't a viable response.

I mean my god, you say you've been using linux for 20+ years, so you surely know, doing this for a performance gain is absurd! We have mega fast SSDs, and an elegant filesystem layer, writing to disk is immensely fast compared to spinning disk days.

We gain almost nothing here, and lose RAM caching of libraries, data, buffers, which the kernel is very, very good at these days too.

It's a dumb default. Immensely so! And statement like "you can just" aren't the point.

This slows almost every single system down.

You know, this could be done right. Instead of stomping on everyone, just create a new tmpfs for just this purpose. Let people use it if they want.

And why on earth suddenly start forcing file cleaning. Debian has not had that default in decades, changing it now because someone else called redhat does it, isn't a valid excuse.

Debian doesn't need to be more like redhat.

Not to mention if you did have a large tmp file that you actually want to persist to a different directory that is on disk you now have to wait for the damn file to be copied from memory to disk vs a single atomic rename operation, this can have major implications depending on the context.

Rename doesn't work across filesystems. You just create a new file and do a regular copy.

Indeed. I'm much more worried about partially deleted files in `/tmp` than the fact that files in `/tmp` do eventually get deleted.

> But automatically deleting files - in either of those - while the system is running is going to break all sorts of things.

Detect the process that created a file and delete it 24 hours after the process ends.

Thanks for the homework assignment. The entire value proposition of tmp is there is no homework to do later.

That will fail badly with multi-process programs, which includes the example of browsers, and many others (databases anyone?).

Chrome is multi-process, isn't it?

Or what about, delete it after 10 days it was last accessed (regardless of whether for read or write)? Hint: that's already how tmpfiles.d works

Reply on news.ycombinator.com