SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
As you can see, /tmp is full before the compile of opencv 2.4.3 completes. I have tried several times, using sbopkg and running the slackbuild in a su- terminal. Every try has failed, in different places, but it fails.
It looks like you have your /tmp in "tmpfs" i.e. in your RAM (possibly because you thought that would speed up compilations, which it will). However, when setting up a tmnpfs in memory, maximally half of your RAM is allocated to the tmpfs by default. That sounds like a lot but if other processes also require the use of RAM, you may end up with a tmpfs which is too small to be useable.
As you can see you have 1.5 GB of tmpfs and it has all been consumed by your /tmp mount.
If you make /tmp a directory in your root filesystem, then you will have 12 GB of free space for compilations.
There is an issue with the way that OpenCV is compiled by default in that it uses precompiled headers, which aren't of much use in SlackBuilds. If you add the following to the cmake options, the amount of disk space required will be reduced by about 2GB and your tmp partition will not fill up:
I spoke with the SlackBuild maintainer about this very topic a couple of weeks ago, and the change has been added for the next update.
I think that putting /tmp in RAM for general use in laptops and desktops has to be classified under "seemed like a good idea at the time". As AlienBob says, you will achieve brilliant performance a few times, but then for the rest of the time that memory will be wasted. Simply leaving it for the O/S to decide what's best to use it for (ie caching reads/writes) is probably a better idea. But that's just my opinion. I wont deny that under certain server workloads, it may well be a good idea to use /tmp in RAM though !
I also understand the need to move /tmp onto the hard drive, so I don't run out of space. However, the how-to's I found talk about making a separate partition for /tmp. Is that necessary? Is there a way to edit /etc/fstab and stop /tmp from mounting to tmpfs, and simply mount to a directory?
As AlienBob says, you will achieve brilliant performance a few times, but then for the rest of the time that memory will be wasted. Simply leaving it for the O/S to decide what's best to use it for (ie caching reads/writes) is probably a better idea
A tmpfs is not a static RAM-disk, it will use exactly the amount of RAM that it needs, not more, not less. So you won't have much waste with the use of tmpfs, just clean up from time to time, like removing the temporary directories used by sbopkg, or just reboot the system.
I edited the slackbuild script, and added the line you suggested. Now I get an error saying the build dir is does not exist. It does, how ever there is nothing in the dir.
Make sure that you don't have a space after the \ at the end of the newly-added line. A backslash indicates that the command continues on the next line, but it has to be the last character on the line or the single command will be broken into two commands.
@TobiSGD - That's pretty much my point - you, the user, has to decide what should be left or deleted from /tmp if you want to keep real memory usage low. At my work, we run a mix of Solaris and Slackware servers. With Solaris, /tmp by default is in virtual memory. As a rule, we tend to code around that and use another directory as "tmp". On occasion we've hit memory issues, as a result of /tmp filling up - waiting to reboot is a bad idea as we tend to only reboot our servers when the diesel power generators need to be tested - ie every 6 months. For the Slackware servers, I setup /tmp to be on disk and I never ever have issues. So if you don't reboot frequently, then one has to write scripts to monitor usage of /tmp and delete (carefully) where files are old. My general feeling is that the odd performance issue you benefit from does not outweigh the downsides of /tmp in RAM. But again, that's an opinion. I strongly suspect that Pat's box that rebuilds Slackware from source would strongly benefit from that - possibly to the point where to not use it would be unfeasible.