[SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

greenjeans · 2025-12-30 21:53:54

From this link: https://www.debian.org/releases/stable/ … in-a-tmpfs

5.1.6. The temporary-files directory /tmp is now stored in a tmpfs
From trixie, the default is for the /tmp/ directory to be stored in memory using a tmpfs(5) filesystem. This should make applications using temporary files faster, but if you put large files there, you may run out of memory.

So is this in Devuan too? Not running excalibur on anything right now so no way to check.

I 100% do not want that behavior on my machine.

The default is to allocate up to 50% of memory to /tmp (this is a maximum: memory is only used when files are actually created in /tmp).

50% of my ram by default... *edit to remove implied profanity because feels*

I swear the debian devs must have just gotten way too bored in 2024, and decided to do random nonsense to pass the time and create more work for everyone, this is almost as stupid and useless as usrmerge.

Last edited by greenjeans (2025-12-31 20:22:40)

HardSun · 2025-12-30 22:33:01

I was a bit confused with this as well, but as it says "memory is only used when files are actually created in /tmp".
From wiki.

The idea behind tmpfs is similar in concept to a RAM disk, in that both provide a file system stored in volatile memory; however, the implementations are different. While tmpfs is implemented at the logical file system layer, a RAM disk is implemented at the physical file system layer. In other words, a RAM disk is a virtual block device with a normal file system running on top of it, while tmpfs is a virtual file system without any underlying block device.

fsmithred · 2025-12-30 22:35:04

I just checked two excaliburs and one ubuntu 24.04. Run 'mount' to see what's on tmpfs. I see tmpfs on a few things in /run and on /dev/shm. In ubuntu I see those plus 'tmpfs on /tmp'. I don't know where these mounts are defined. It's not in fstab.

'du -sh /run' shows around 780K used in devuan and 1.1M used in ubuntu.

HardSun · 2025-12-30 22:42:17

fsmithred, you can tweak tmpfs settings in /etc/default/tmpfs
But yeah im not sure where the hard coded settings for tmpfs are

EDX-0 · 2025-12-31 04:16:39

debian trixie does that with a systemd service iirc, devuan is not affected, not that you cannot mount /tmp or any other dir as a tmpfs if you want to for some usecase, just do it in fstab i guess.

as for the output of mount in a devuan excalibur system

mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=7816860k,nr_inodes=1954215,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1576544k,mode=755,inode64)
/dev/nvme0n1p4 on / type btrfs (rw,noatime,compress=zstd:10,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/@rootfs)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
securityfs on /sys/kernel/security type securityfs (rw,relatime)
pstore on /sys/fs/pstore type pstore (rw,relatime)
none on /sys/firmware/efi/efivars type efivarfs (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=7840540k,inode64)
/dev/nvme0n1p2 on /boot type ext2 (rw,relatime)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/nvme0n1p5 on /home type btrfs (rw,noatime,compress=zstd:10,ssd,discard=async,space_cache,subvolid=5,subvol=/)
/dev/sda1 on /media/storage type btrfs (rw,noatime,compress=zstd:10,ssd,discard=async,space_cache,subvolid=5,subvol=/)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
tmpfs on /run/user/112 type tmpfs (rw,nosuid,nodev,relatime,size=1576540k,nr_inodes=394135,mode=700,uid=112,gid=121,inode64)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1576540k,nr_inodes=394135,mode=700,uid=1000,gid=1000,inode64)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Last edited by EDX-0 (2025-12-31 04:17:15)

steve_v · 2025-12-31 04:59:18

greenjeans wrote:

So is this in Devuan too?

It's optional, same as it always was:

# mount /tmp as a tmpfs.  Defaults to no; set to yes to enable (/tmp
# will be part of the root filesystem if disabled).  /tmp may also be
# configured to be a separate mount in /etc/fstab.
#RAMTMP=no

greenjeans wrote:

50% of my ram by default... i'm too f***ing sure, how do they come up with this bullshit?

They "come up with this", because it's a thing many other distros do by default and many users used to do manually, which reduces SSD writes and improves latency for applications that make frequent use of /tmp.

"50% of my ram" is a default upper limit, actual memory consumption for tmpfs (unlike a traditional ramdisk) is dynamic.
On most systems /tmp is only a few MiB, and has negligible impact on available memory. If you want to stash huge files there for some reason, simply disable or configure it to your liking. See man tmpfs(5). Note that as per FHS, /tmp is not expected to survive a reboot either way.

HardSun wrote:

im not sure where the hard coded settings for tmpfs are

/lib/init/tmpfs.sh, which is called from /etc/init.d/mountall.sh, which is illuminated by a couple of seconds with grep. I'm not sure what the big mystery here is.

Last edited by steve_v (2025-12-31 05:07:34)

HardSun · 2025-12-31 07:56:23

steve_v wrote:

/lib/init/tmpfs.sh, which is called from /etc/init.d/mountall.sh, which is illuminated by a couple of seconds with grep. I'm not sure what the big mystery here is.

How did you come to the conclusion it was a big mystery? I just dont know enough about the subject.

steve_v · 2025-12-31 10:08:35

The tmpfs functionality is not mysterious, but this thread kinda is:
a) We begin with a swearing rant about Debian, rather than reading the man pages or conf file where this is all explained.
b) Two people in a row go with "I don't know", rather than just doing 'grep -r tmpfs /etc/' and finding out.

Some days I really wonder if this whole board isn't just a place to bitch about upstreams, other distros, and anyone who ever dared to change anything.
Here I was thinking "other issues" was for questions and technical support.

Last edited by steve_v (2025-12-31 10:12:09)

greenjeans · 2025-12-31 15:25:19

Steve, the milk of human kindness come to warm the place up again, happy New Year buddy!

which reduces SSD writes

I'll admit, hadn't thought of that angle, as I run spinning rust and not short-life-expectancy ssd's.

improves latency for applications that make frequent use of /tmp.

Horsefeathers. They're both solid-state, there won't be a noticeable difference. There won't even be much of a difference on a machine like mine with an HDD. If I wanted everything in ram i'd load a live-session.

On most systems /tmp is only a few MiB, and has negligible impact on available memory.

It's not the only thing living in ram these days, ram usage overall is more than double what it was a few short years ago, and there's lots of people running old hardware with low ram that need the extra. Not everybody has 32-64 gigs of ram, some folks are on a budget, i'm running 4 gb myself and i'd like to keep it clear.

So it's good to know now that i'll have a choice in the matter, which was the whole point of the post.

Some days I really wonder if this whole board isn't just a place to bitch about upstreams, other distros, and anyone who ever dared to change anything.

People have a right to do these things, if nobody ever complained every system in the world would suck.

And lastly, for myself, I don't just complain, I do something about it pretty regularly.

Srsly, hope you had a good Christmas and all the best to you and family in the New Year!

steve_v · 2025-12-31 18:19:57

They're both solid-state, there won't be a noticeable difference.

Main memory latency is measured in nanoseconds, while even the fastest NVME SSDs are in the tens of microseconds. On older storage technology the gap is considerably larger.
An order of magnitude is "not noticeable"? That must be why Solaris started putting /tmp in RAM around 1994.

there's lots of people running old hardware with low ram that need the extra. Not everybody has 32-64 gigs of ram

We're talking about Debian turning this on by default, not forcing you to use it. The vast majority of Debian (and GNU/Linux in general) deployments are servers, where 32GB is generally considered low-end. Setting the default to suit that use case while having minimal impact** on everyone else is perfectly reasonable.

Most mobile phones have more than 4GB of RAM these days, if you want to use antique hardware, that's cool... But expecting defaults in a general purpose distro to be tailored for that is ridiculous.

**
Devuan server, manual max size set, 38MB used:

tmpfs            2.0G   38M  2.0G   2% /tmp

Oh noes, 0.03% of precious RAM wasted on my 14 year old hardware.

My Gentoo desktop does not currently have /tmp in RAM, because I have a tendency to compile stuff there and old (bad) habits die hard.

Last edited by steve_v (2025-12-31 18:41:07)

greenjeans · 2025-12-31 20:17:53

But expecting defaults in a general purpose distro to be tailored for that is ridiculous.

Read the above that you wrote again, very slowly, and focus on the bolded part.

"general purpose" to me means it can work on anything, and I never said I expected things to be tailored to my hardware.

"defaults" ought to start with the lowest common denominator, it ought to work perfectly on older hardware, and thusly will work even better on newer machines. Users with better hardware are then free to bolster their system with various speed tweaks if needed.

Oh noes, 0.03% of precious RAM wasted on my 14 year old hardware.

omg well for sure move 0.03% of stuff into ram then, my gawd we've saved SO MUCH speed because lawd knows it will take my machine just forever to read that stuff. I do love saving me some tenths of microseconds.

You're just complaining now about me having the nerve to complain Steve, possibly you may want to ignore me because i'll likely complain again before it's all over with.

HardSun · 2025-12-31 22:15:43

steve_v wrote:

The tmpfs functionality is not mysterious, but this thread kinda is:
a) We begin with a swearing rant about Debian, rather than reading the man pages or conf file where this is all explained.
b) Two people in a row go with "I don't know", rather than just doing 'grep -r tmpfs /etc/' and finding out.

It just didnt occur to me to use grep on etc, instead i went to the kernel docs about tmpfs.
I didnt understand most of it, so left it alone less i spread ~~fud~~ misleading info.
https://www.kernel.org/doc/html/latest/ … tmpfs.html

Last edited by HardSun (2025-12-31 22:19:43)

steve_v · 2025-12-31 23:47:41

"defaults" ought to start with the lowest common denominator

s/lowest/most/g

it ought to work perfectly on older hardware

It does, <50MiB of memory is trivial on any readily available consumer hardware outside of embedded platforms - and if you're deploying on those you're going to be pulling more tricks than this.

Users with better hardware are then free to bolster their system with various speed tweaks if needed.

Users with antique hardware are free to bolster their system with various memory-conserving tweaks if needed.

Wasting memory is just that, but trading memory for speed is a more subtle question and more often than not it's a net positive. Something that is a net positive for the majority of use cases (4GB RAM or 32bit haven't been that for a decade) is a good candidate for default configuration.

This is moot WRT Devuan in any case, because the defaults haven't changed since they inherited the init scripts from Debian.

Last edited by steve_v (2025-12-31 23:48:48)

greenjeans · 2026-01-01 00:15:32

Points well-taken, perhaps I did overreact a bit. In any case this query is now solved. So thanks to all who weighed in.

The officially official Devuan Forum!

#1 2025-12-30 21:53:54

[SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

#2 2025-12-30 22:33:01

Re: [SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

#3 2025-12-30 22:35:04

Re: [SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

#4 2025-12-30 22:42:17

Re: [SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

#5 2025-12-31 04:16:39

Re: [SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

#6 2025-12-31 04:59:18

Re: [SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

#7 2025-12-31 07:56:23

Re: [SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

#8 2025-12-31 10:08:35

Re: [SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

#9 2025-12-31 15:25:19

Re: [SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

#10 2025-12-31 18:19:57

Re: [SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

#11 2025-12-31 20:17:53

Re: [SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

#12 2025-12-31 22:15:43

Re: [SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

#13 2025-12-31 23:47:41

Re: [SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

#14 2026-01-01 00:15:32

Re: [SOLVED] tmp files now stored in a tempfs? Excalibur/Trixie

Board footer