4 ms·

I don’t like it, I tend to use /tmp for large files or directories that are just that - temporary. Now they will either fill up my RAM or require a large swap

I don’t like it, I tend to use /tmp for large files or directories that are just that - temporary. Now they will either fill up my RAM or require a large swap partition (which I usually don’t have as it’s otherwise wasted space). I really like making /tmp the default destination for downloads, so either I need the file and move it elsewhere, but usually it’s an archive and I just want a file from it. Saves me from an ever growing Download folder. Those files are most dispensable and should not consume precious RAM. Some file systems are even adding specific tmpdir support where fsync() is turned into a noop. So they have all the advantages of tmpfs without eating into precious RAM/Swap.

stouset 2y ago
It's a default. You can change it.
- pantalaimon 2y ago
  Only on my personal machine. If I’m logged in elsewhere and keep my habit of working on large files in /tmp, I will be in for a bad surprise
  - stouset 2y ago
    So… don’t keep large files you want to control the lifecycle of in directories you don’t own? If you care about it, stop putting it in /tmp. You were always setting yourself up for a bad surprise by doing this, and now you’re surprised?
    - pantalaimon 2y ago
      I might download an ISO or check out a repo I want to build just once. Or copy some (large) files there because I run a script on them and persevere the original in case something goes wrong. I don’t care about those files once I’m done with them - so far they would only be gone with a reboot, which aligns well with my definition of done.
      - yjftsjthsd-h 2y ago
        If you really don't want to delete manually you can just `sudo mount -t tmpfs ~/tmp` or so
      - stouset 2y ago
        If you’re downloading large files (so large you’re concerned about an in-memory tmpfs) to boxes that you don’t own, stop just leaving them around in the first place. Sure, /tmp is cleaned on boot. But if the host is rarely rebooted it’s pretty inconsiderate to just leave enormous quantities of unneeded crap lying around in shared directories. /tmp isn’t supposed to be a garbage dump. It’s supposed to be for data that’s actually in use but transient or relevant to running processes. You’re still expected to be a good citizen on shared hosts and clean up after yourself when you’re done.
  - Macha 2y ago
    This is true already if your remote machine is red hat, fedora, arch, opensuse, rocky, ...
NekkoDroid 2y ago
There is still /var/tmp if you want a disk backed temporary file storage.
- pantalaimon 2y ago
  But is this also cleaned up on boot? The reason I’m doing this in /tmp is that I can just shut down the computer and have all those staging files gone. (Same reason I shut the computer down at the end of the day instead of suspend - I want to start with a clean slate the next day)
  - NekkoDroid 2y ago
    It isn't cleaned up at boot IIRC. Unless you leave your computer off for 30 days and then come back [1] :). But it shouldn't be too hard to write a relativly simple systemd.unit file that does that at boot. After all the main part would be `Requires/After=local-fs.target` and something like `ExecStart=bash -c 'rm -rf /var/tmp/*'` I think (you'd need to double check what exactly to do if you want to do this). [1] https://github.com/systemd/systemd/issues/33162 https://github.com/systemd/systemd/issues/33162
    - rcxdude 2y ago
      There's also systemd-tmpfiles for this exact purpose (well, it's a more general purpose create-a-directory-structure config system, but this is one of its usecases).

stouset 2y ago

It's a default. You can change it.

pantalaimon 2y ago
Only on my personal machine. If I’m logged in elsewhere and keep my habit of working on large files in /tmp, I will be in for a bad surprise
- stouset 2y ago
  So… don’t keep large files you want to control the lifecycle of in directories you don’t own? If you care about it, stop putting it in /tmp. You were always setting yourself up for a bad surprise by doing this, and now you’re surprised?
  - pantalaimon 2y ago
    I might download an ISO or check out a repo I want to build just once. Or copy some (large) files there because I run a script on them and persevere the original in case something goes wrong. I don’t care about those files once I’m done with them - so far they would only be gone with a reboot, which aligns well with my definition of done.
    - yjftsjthsd-h 2y ago
      If you really don't want to delete manually you can just `sudo mount -t tmpfs ~/tmp` or so
    - stouset 2y ago
      If you’re downloading large files (so large you’re concerned about an in-memory tmpfs) to boxes that you don’t own, stop just leaving them around in the first place. Sure, /tmp is cleaned on boot. But if the host is rarely rebooted it’s pretty inconsiderate to just leave enormous quantities of unneeded crap lying around in shared directories. /tmp isn’t supposed to be a garbage dump. It’s supposed to be for data that’s actually in use but transient or relevant to running processes. You’re still expected to be a good citizen on shared hosts and clean up after yourself when you’re done.
- Macha 2y ago
  This is true already if your remote machine is red hat, fedora, arch, opensuse, rocky, ...

NekkoDroid 2y ago

There is still /var/tmp if you want a disk backed temporary file storage.

pantalaimon 2y ago
But is this also cleaned up on boot? The reason I’m doing this in /tmp is that I can just shut down the computer and have all those staging files gone. (Same reason I shut the computer down at the end of the day instead of suspend - I want to start with a clean slate the next day)
- NekkoDroid 2y ago
  It isn't cleaned up at boot IIRC. Unless you leave your computer off for 30 days and then come back [1] :). But it shouldn't be too hard to write a relativly simple systemd.unit file that does that at boot. After all the main part would be `Requires/After=local-fs.target` and something like `ExecStart=bash -c 'rm -rf /var/tmp/*'` I think (you'd need to double check what exactly to do if you want to do this). [1] https://github.com/systemd/systemd/issues/33162 https://github.com/systemd/systemd/issues/33162
  - rcxdude 2y ago
    There's also systemd-tmpfiles for this exact purpose (well, it's a more general purpose create-a-directory-structure config system, but this is one of its usecases).