New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nixos/tmp: Make /tmp on ramdisk usable again #107497
Conversation
nixos/modules/system/boot/tmp.nix
Outdated
{ | ||
what = "tmpfs"; | ||
where = "/tmp"; | ||
mountConfig.Options = [ "mode=1777" "strictatime" "rw" "nosuid" "nodev" "size=50%" "huge=within_size" ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can the huge=within_size
be in a separate commit at least? It feels like a performance optimization that should be done on top of a fix (as in, if it causes regressions, I want to be able to revert it separately).
I'd even argue and say this is something very special that users should probably set on their own (or why is it not a default in general?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the option altogether since people who want to use this functionality can just use the module systems's merge function to add options.
@poettering decided we only need a limited number of inodes in our /tmp, so why not limit that for every systemd user? That makes medium-sized nix builds impossible so this commit restores the old behaviour which is the kernel default of half the number of physical RAM pages which does not seem too unreasonable to me.
After applying this change to one of my machines, the
This documentation (https://www.freedesktop.org/software/systemd/man/systemd.mount.html) suggests that |
Let's not be aggressive towards Lennart. We're not the first downstream to have to undo this coreos/fedora-coreos-config#685, and in nixos alone our |
Are there any plans to back port this fix to 20.09? I just ran into the same problem, wondering how a build can fail on a 128GB tmpfs:
from (20.09.2344.a3a3dda3bac) |
Is it possible to add a test for this kind of issues? Cause this is a pretty severe issue. |
#107497 broke booting on many systems that use tmpOnTmpfs due to the lack of specifying the mount type. This commit explicitly adds the mount type, which should fix booting such systems. The original change may want to be revisited however too.
NixOS#107497 broke booting on many systems that use tmpOnTmpfs due to the lack of specifying the mount type. This commit explicitly adds the mount type, which should fix booting such systems. The original change may want to be revisited however too.
NixOS#107497 broke booting on many systems that use tmpOnTmpfs due to the lack of specifying the mount type. This commit explicitly adds the mount type, which should fix booting such systems. The original change may want to be revisited however too.
Apparently this doesn't work as expected: #157512 (not sure if something else changed in the meantime) |
@poettering decided we only need a limited number of inodes in our /tmp,
so why not limit that for every systemd user? That makes medium-sized nix
builds impossible so this commit restores the old behaviour which is the
kernel default of half the number of physical RAM pages which does not
seem too unreasonable to me.
Motivation for this change
I want to build stuff
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)