-
Notifications
You must be signed in to change notification settings - Fork 842
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
Avoid writing large amounts of data to system temp directory #996
Comments
Their article says tmpfs on Arch defaults to having its max size be half total RAM. https://wiki.archlinux.org/index.php/Tmpfs#Examples |
The downside to not using a proper temp directory is that if the process fails halfway through, the disk space is never reclaimed. |
If that's a concern, what about using say https://hackage.haskell.org/package/temporary-1.2.0.3/docs/System-IO-Temp.html#v:withSystemTempDirectory ? Or are you referring to the Haskell process crashing? |
I'm referring to the Haskell process crashing (or system simply shutting down). And that's the function we're using already; the problem is Arch's setup not providing enough disk space in the temp directory. |
I think other distros using systemd will have /tmp be tmpfs, too (edit: Sorry, apparently that's not the case. e.g. I don't think RedHat / CentOS have this; maybe just Arch and CentOS?). E.g. Fedora since version 18. http://fedoraproject.org/wiki/Features/tmp-on-tmpfs |
I figured we'd have stack check for that and free it up. This way, the only case where disk space is never reclaimed is if stack isn't run again. Could get a bit tricky with concurrent stack executions, though.. |
That Fedora page mentions a workaround: If indeed /var/tmp is supposed to become some standard alternative to /tmp for large files; it makes one think there ought to be similar env vars for referencing it, and a corresponding method in System.Directory for getting its value in some cross-platform way? |
http://fedoraproject.org/wiki/Features/tmp-on-tmpfs#Detailed_Description says /tmp on tmpfs is becoming more common. Not sure of a cross-platform way of specifying /var/tmp; seems like that functionality might belong in System.Directory, anyways. Perhaps we could just check if it exists. Proposed behaviour: Check for Though, articles I read seem to dissuade /tmp and /var/tmp (especially when not being used to communicate between processes) due to security concerns, and suggest something like XDG user dirs (or somewhere in |
I just ran into this issue. I have a VM setup where the root fs is mounted readonly and (therefore) /tmp is mounted as tmpfs with limited amount of space available. There is sufficient space available in /var/tmp though. I know of at least one big installation where many systems are booted from the same image which is mounted over NFS. In such cases /tmp is mounted as a RAM file system. Though usually in enterprise settings the available RAM is usually enough to provide sufficient space but I guess there may be cases where /tmp is limited in space. However /var/tmp should usually have enough space. Preferring /var/tmp over /tmp might be a good idea. |
Unfortunately, It sounds like there's a strong need for a portable way of finding a tmp directory that's on local disk, not in memory, and not on the network. |
There doesn't seem to be any perfect solution to this, but I think writing big temporary files under Advantages:
Disadvantages:
We must ensure any error messages about disk space are clear and offer workarounds. |
Sounds good. Can we first check the amount of space available in a given volume before we try another one? We can try /tmp, $HOME, /var/tmp in that order based on the amount of space available. That way we will be able to try our best and bail out only if it is not at all possible to install. Space check will also allow us to provide a way to gracefully exit with an error message rather than trying and running out of space. |
Another reason to manage our own tmp directory is that we can make the process invocations in the verbose log copy+pasteable. Currently, some commands don't work due to the temporary files being eagerly deletd. See the first point of #1596 for more info. |
Note that you need an absolute path e.g. |
I've fixed this! The downside is that now there will be dirs leftover that the user will need to cleanup (unless they try to do setup again). This is even the case where stack gets to handle the exceptions, etc. The reason for this is that configure errors + etc say things like |
Also gives a good error message letting you know that directories now exist which won't be used by stack
+ remove readInNull utility. I think "exitFailure" should be mentioned upfront.
Also gives a good error message letting you know that directories now exist which won't be used by stack Also removes readInNull utility. I think "exitFailure" should be mentioned upfront.
I am now experiencing the exact opposite issue: I tried the following:
To be able to support both the original scenario in this issue and the case of a small (or slow for that matter, as mentioned before here too) home directory, it would be nice if the download location were configurable. As there is And shouldn’t GHC be installed to |
As far as I can git grep, Stack does not use TMP or TEMP or TEMPDIR any more. As of commercialhaskell#996, stack setup does not download to the system temp directory any more.
As far as I can git grep, Stack does not use TMP or TEMP or TEMPDIR any more. As of commercialhaskell#996, stack setup does not download to the system temp directory any more.
Reported by joseph07 in #haskell.
stack setup
failed due to not having enough space on the device, despite there being 38GB. According to pdxleif, archlinux defaults to using tmpfs, which stores it in ram, and so is limited in size.Here's where a system temp directory is used as a place to unpack the GHC tarball:
stack/src/Stack/Setup.hs
Line 760 in c0525a2
It'd also likely be worthwhile to take a look at other usages of the system temp directory. On one hand, it seems odd to have a system configuration that has such limited space in tmp. On the other hand, I see few downsides to instead storing such temp directories somewhere in
~/.stack
(and the big upside of resolving this issue)The text was updated successfully, but these errors were encountered: