Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

lowendbox.com

Post reply on HN
Print view View original

111–120 of 137 posts

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#111

Post by guappa »

Hendrikto wrote: post #86
1718627440 wrote: post #81

Earlier quoted context omitted.

I thought /var/tmp is for applications while /tmp is for the user.

> /tmp/ > The place for small temporary files. This directory is usually mounted as a tmpfs instance, and should hence not be used for larger files. (Use /var/tmp/ for larger files.) This directory is usually flushed at boot-up. Also, files that are not accessed within a certain time may be automatically deleted. Source: https://uapi-group.org/specifications/specs/linux_file_syste...

But that was written after the change was made :D

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#112

Post by throw0101c »

1718627440 wrote: post #81
nolist_policy wrote: post #68

Earlier quoted context omitted.

Use `/var/tmp` of you want a disk backed tmp.

I thought /var/tmp is for applications while /tmp is for the user.

> I thought /var/tmp is for applications while /tmp is for the user.

/tmp is for stuff that is 'absolutely' temporary, in that on many/most systems it is nuked between reboots. /var/tmp is 'relatively' temporary in that applications can put stuff there that they're working on, but if there is a crash, the contents are not deleted and can be recovered across reboots.

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#113

Post by throw0101c »

k_bx wrote: post #26
gnyman wrote: post #18

Earlier quoted context omitted.

Note though that if you don't have swap now, and enable it, you introduce the risk of thrashing [1] If you have swap already it doesn't matter, but I've encountered enough thrashing that I now disable swap on almost all servers I work with. It's rare but when it happens the server usually becomes completely unresponsive, so you have to hard reset it. I'd rather that the application trying to use too much memory is ki…

Disabling swap on servers is de-facto standard for serious deployments. The swap story needs a serious upgrade. I think /tmp in memory is a great idea, but I also think that particular /tmp needs a swap support (ideally with compression, ZSWAP), but not the main system.

> Disabling swap on servers is de-facto standard for serious deployments.

I guess I have not been deploying seriously over the last couple of decades because the (hardware) systems that I deploy all had some swap, even if it was only a file.

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#114

Post by k_bx »

throw0101c wrote: post #113
k_bx wrote: post #26

Earlier quoted context omitted.

Disabling swap on servers is de-facto standard for serious deployments. The swap story needs a serious upgrade. I think /tmp in memory is a great idea, but I also think that particular /tmp needs a swap support (ideally with compression, ZSWAP), but not the main system.

> Disabling swap on servers is de-facto standard for serious deployments. I guess I have not been deploying seriously over the last couple of decades because the (hardware) systems that I deploy all had some swap, even if it was only a file.

What's your swappiness ?

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#115

Post by Suzuran »

nolist_policy wrote: post #48
Incipient wrote: post #17

Using the example from the article, extracting an archive. Surely that use case is entity not possible using in-memory? What happens if you're dealing with a not-unreasonable 100gb archive? Who runs around with 100gb+ of swap?!

Use `/var/tmp` of you want a disk backed tmp. Not sure why the article omits that.

/var/tmp is not allowed if you wish to pass security audits, it MUST be a bind mount to /tmp

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#116

Post by Suzuran »

blueflow wrote: post #107
mnw21cam wrote: post #73

Earlier quoted context omitted.

It's also because a filesystem is much more likely to have consecutive parts of a file stored consecutively on disc, whereas swap is going to just randomly scatter 4kB blocks everywhere, so you'll be dealing with random access read speed instead of throughput read speed.

Valid argument with FAT on spinning rust, invalid with ext4 on ssd. ext4 is extent-based so the fragmentation overhead doesn't happen.

The swap partition does not have a filesystem, it is a linear list of blocks.

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#117

Post by [deleted] »

Suzuran wrote: post #116
blueflow wrote: post #107

Earlier quoted context omitted.

Valid argument with FAT on spinning rust, invalid with ext4 on ssd. ext4 is extent-based so the fragmentation overhead doesn't happen.

The swap partition does not have a filesystem, it is a linear list of blocks.

[deleted]

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#118

Post by blueflow »

Suzuran wrote: post #116
blueflow wrote: post #107

Earlier quoted context omitted.

Valid argument with FAT on spinning rust, invalid with ext4 on ssd. ext4 is extent-based so the fragmentation overhead doesn't happen.

The swap partition does not have a filesystem, it is a linear list of blocks.

Neither i nor parent said that. Confusion?

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#119

Post by 1718627440 »

pessimizer wrote: post #102
1718627440 wrote: post #82

Earlier quoted context omitted.

Programs shouldn't assume that about /tmp, the user advising this is fine.

The user wasn't "advising" this, or asking if it was fine. They're just doing it. Everything that they want to do with their own computer is permissible. The person you're replying to is saying that tmp is meant for temporary storage that could disappear between reboots. A permanent archive of the past states of the tmp directory is not temporary.

I meant from the perspective of the program. You can't assume /tmp to be stable, but when the user tells you it's fine, then it is fine.

> A permanent archive of the past states of the tmp directory is not temporary.

From the perspective of a program it's still volatile, since the files don't stay in their original place.

Re: A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

#120

Post by Scaevolus »

blueflow wrote: post #97
fh973 wrote: post #23

Swap on servers somewhat defeats the purpose of ECC memory: your program state is now subject to complex IO path that is not end-to-end checksum protected. Also you get unpredictable performance. So typically: swap off on servers. Do they have a server story?

First, having no swap means anonymous pages cannot be evicted, named pages must be evicted instead. Second, the binaries of your processes are mapped in as named pages (because they come from the ELF file). Named pages are generell not understood as "used" memory because they can be evicted and reclaimed, but if you have a service with a 150MB binary running, those 150MB of seemingly "free" memory are absolutely cruc…

Swapping anonymous pages can bring the system to a crawl too. High memory pressure makes things very slow with swap, while with swap off high memory pressure is likely to invoke the oom killer and lets the system violently repair.
Post reply on HN