Bug 243523
| Summary: | The default size of tmpmfs is not sufficient for pkg operation | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Victor Sudakov <vas> |
| Component: | conf | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | In Progress --- | ||
| Severity: | Affects Some People | CC: | bc979, ceri, cy, emaste, grahamperrin, vas, wosch |
| Priority: | --- | ||
| Version: | 12.1-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Victor Sudakov
2020-01-22 17:09:19 UTC
What size did you end up using? (In reply to Ed Maste from comment #1) I have actually given up using RAM for /tmp as I don't see much sense in it. My current FreeBSD systems are on ZFS where zroot/tmp is mounted on /tmp. I think it is save to give the temp filesystem 1/10 or 1/4 of your available RAM. Given that most if not all FreeBSD users will have 512MB for a VM I suggest to increase the default value to 128MB. *** Bug 268711 has been marked as a duplicate of this bug. *** Being old-school I create mine in fstab, like Tru64 did. (Sun Solaris back in the day had no limit but it was easy for users to create an OOM situation by filling /tmp.) IIRC 20m was sufficient in 1995 however currently 300m is probably better for most applications today. It is advised not to change the default. The default is set to allow installation on embedded and small systems. Increasing the default to satisfy desktop users is not recommended. What is recommended is to add a knob to the installer which will set a higher limit in rc.conf or it could add a line to fstab (like Tru64 and Solaris did). But to increase the default just for desktop users is not a good idea. For the time being desktop users can add a line to rc.conf increasing the limit to 300m or add an fstab entry with no limit whatsoever, while consideration to add a question in the installer about whether the machine is a desktop in order to add the increased value to rc.conf. Another way to solve this is to add a desktop="NO" to etc/defaults/rc.conf. When set to "YES" bump the value to 300m. Let me reiterate. Users can solve this themselves by tmpsize="300m" in rc.conf and rebooting. (In reply to Cy Schubert from comment #6) Thanks, and for what it's worth, I see this now as primarily a documentation issue. In rc.conf(5), the paragraph for tmpmfs will benefit from a hint that by default, the size is limited. (The existence of a limit surprised me, because I was accustomed to fstab(5) for /tmp with tmpfs.) (In reply to Cy Schubert from comment #5) With a run of two Electron-based applications (see bug 268711 comment 1) plus Microsoft Teams and <https://app.element.io/> in tabs in Chromium, I successfully hit a 300m ceiling by (Control-F5, cache bypass) reloading both tabs and then forcing a package update in Konsole. In the moments before unexpected disappearance of Chromium: % df -h /tmp Filesystem Size Used Avail Capacity Mounted on tmpfs 300M 257M 43M 86% /tmp % df -h /tmp Filesystem Size Used Avail Capacity Mounted on tmpfs 300M 295M 5.2M 98% /tmp More thought-provoking (but almost certainly off-topic – anyone who's interested can join me elsewhere, in chat): * none of the prior uses of Control-F5 brought the Chromium view of Element up-to-date * the second start of Chromium was preceded by intentional quit of most other applications – aiming to minimise use of /tmp – in this case, the first use of Control-5 _did_ have the required effect. (In reply to Cy Schubert from comment #6) Embedded users are surely customising further anyway, so I’m not sure why such use cases should win out over something useable for the majority case. What actually happens if a size too large for the system is specified? I presume an immediate error message somewhat more obviously related to the problem? In cases where someone has somehow ended up with an unwritable /tmp and the AUTO case kicks in, it may be some time before they try to do something and can’t work out why it’s failing. POLA suggests a larger default is the better choice. On a RaspberryPi 4, the 14.0-RELEASE size is 50m, but that is still too small. pkg upgrade dies with somewhat appropriate errors. I had to set it to 128m to get pkg upgrade to work. FreeBSD 14.1RELEASE has 34072 packages, in total 127 GB, uncompressed 397 GB (zstd compression by a factor of 3.1) Most packages are small, the medium size is 65 KB. There are 2299 packages greater than 5 MB compressed which may *not* fit on an 20 MB tmpfs There are 462 packages greater than 50 MB compressed which may *not* fit on an 128 MB tmpfs There are 240 packages greater than 100 MB compressed which may *not* fit on an 256 MB tmpfs There are 67 packages greater than 300 MB compressed which may *not* fit on an 1GB tmpfs There are 11 packages greater than 1GB, and the largest is uncompressed 3.2GB huge. |
