#gentoolinux — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #gentoolinux, aggregated by home.social.
-
Not a #TIL (Today I Learned) about Linux, but a common misunderstanding I see in every Arch installation guide that isn't the ArchWiki:
People want to enable TRIM to conserve their SSD's lifespan, and thus they execute the following command:
```
systemctl enable --now fstrim.timer
```That command by itself does absolutely nothing. All it does is create a scheduled job to trim (that is, discard unused blocks) the SSD (by default once a week), but it will (silently) fail every single week because the SSD's support for TRIM was never activated.
You can verify for yourself that this is true by executing the following command. It will tell you (for all mounted filesystems) that TRIM isn't supported by this device.
```
fstrim --all --verbose
```Alternatively, execute this:
```
lsblk --discard
```What you need to also do is enable TRIM support when you decrypted your encrypted partition, by passing the two flags `--allow-discards --persistent`.
```
partition='sda2'
device_mapper_file_name='root'cryptsetup --allow-discards --persistent open \
/dev/${partition} \
${device_mapper_file_name}
```The `cryptsetup` command with the `--persistent` flag and `--allow-discards` flag will activate the TRIM flag in the LUKS metadata. You need to set this flag only once.
Use the command `cryptsetup refresh` rather than `cryptsetup open` for already existing installations.
Now the command `fstrim --all --verbose` should execute successfully, showing you that TRIM is correctly set up.
-
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you unless you tell it not to. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might, for example, dowload the 1.5 GiB Arch ISO to /tmp rather than to ~/Downloads, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you unless you tell it not to. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might, for example, dowload the 1.5 GiB Arch ISO to /tmp rather than to ~/Downloads, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you unless you tell it not to. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might, for example, dowload the 1.5 GiB Arch ISO to /tmp rather than to ~/Downloads, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you unless you tell it not to. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might, for example, dowload the 1.5 GiB Arch ISO to /tmp rather than to ~/Downloads, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you unless you tell it not to. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might, for example, dowload the 1.5 GiB Arch ISO to /tmp rather than to ~/Downloads, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap