4 ms·

/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

by b112 2y ago

/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

zepolen 2y ago
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.
- guappa 2y ago
  Rename doesn't work across filesystems. You just create a new file and do a regular copy.
bildung 2y ago
> 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.
- b112 2y ago
  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.
ChoHag 2y ago
[dead]

by b112 2y ago

zepolen 2y ago

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.

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

bildung 2y ago

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

b112 2y ago
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.

ChoHag 2y ago

[dead]