Atlantis Neo install creates a tmpfs line in fstab. Is it needed? ...and mount options regarding SSD too


When I install EOS with btrfs(onluks), there is an added line in fstab to mount /tmp on tmpfs:

tmpfs           /tmp          tmpfs   defaults,noatime,mode=1777 0 0

I though that was unnecessary (as per the wiki)
Do I miss something ?

Also, I see that the discard=async and ssd options are enabled, is that “better”?
So, no need of fstrim.timer anymore I assume? I thought I read somewhere that timer was “better” (less disk i/o and i.e. better lifespan) than discard unless you have To of data erased each day…
And I’m a bit confused with the ssd mount point as per the btrfs documentation

Note: Since 4.14, the block layout optimizations have been dropped. This used to help with first generations of SSD devices. Their FTL (flash translation layer) was not effective and the optimization was supposed to improve the wear by better aligning blocks. This is no longer true with modern SSD devices and the optimization had no real benefit. Furthermore it caused increased fragmentation. The layout tuning has been kept intact for the option ssd_spread.

Cheers !

P.S.: thank you so much for this wonderful distro guys!!! :penguin_face: :rocketa_purple: :enos_flag: :enos:

1 Like

fstrim.timer is enabled by default since Atlantis. So I think that discard is not in use.

Don’t know much about the tmpfs. if it’s not breaking anything no harm just letting it be.

1 Like

I don’t have this line in /etc/fstab on an Arch install. Yet I’ll get:

tmpfs          tmpfs     3.8G  8.2M  3.7G   1% /tmp
tmpfs          tmpfs     760M   76K  760M   1% /run/user/1000

from df -hT.


Perhaps you could comment the line out in /etc/fstab, reboot and check if it will get mounted as it should by systemd’s tmp.mount.

1 Like

I guess that’s even “worse” then :-/ as per my understanding it should be one or the other, not both, right?

Yes totally, I didn’t have this line on another similar install and it was mounted right. I will follow your advice and delete it.

The “problem” is that is what the EOS installer created by default…

1 Like

This is my fstab. Well, the SSD part.

# Main SSD
UUID=D57D-B3B3                            /boot/efi      vfat    umask=0077 0 2
UUID=f2f94842-8952-4808-9752-1a9608e5af53 /              ext4    defaults,noatime 0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

But this is not from atlantis. I do that trim enabled for this drive but don’t know how you got that discard in yours though. If trim is there you don’t need discard. I also have the tmpfs mount which is pointed toward /tmp.

1 Like

According to Dalto, it doesn’t hurt to have both options.

1 Like

As he says it’s better if the drive is full if not fstrim.timer is enough. And he’s typing a reply.

1 Like

It is created by calamares, which isn’t Arch-specific.

The ssd option does nothing in this case since btrfs and Calamares use the same mechanism for detecting your ssd. However, it won’t hurt anything either.

discard=async is a performant way of doing discard/trim. It isn’t better or worse than the fstrim.timer in an absolute sense. It depends on your situation. Using both discard=async and the fstrim.timer is not necessary but it also won’t hurt anything. You will just get an extra trim operation once a week.

EDIT: I should probably point out that on my personal machines I don’t use discard=async and only use the fstrim timer.

That being said, feel free to alter any of those settings to meet your specific needs. You should look at the settings the installer provides as a best-effort starting point, not an absolute truth.

1 Like

So I did miss something :upside_down_face:

Just more disk operations, “theoretically” reducing SSD lifespan?



Thank you so much @s4ndm4n @pebcak @anon49550872 and @dalto for your insight and help!
I’ll tweak the fstab from there. (get rid of tmpfs line, ssd and discard=async options too)

Cheers !