Simple way to not fill up /?

  • Thread starter Thread starter Anonymous
  • Start date Start date
A

Anonymous

Guest
If I build, e.g., firefox as root, it consumes an enormous amount of space in /. But if I # su over to my non-root group-wheel account, I run into permission problems when trying to # make install.

Is there a cheaper way around that than doing a lot of # chmod and/or # chown?
 
Ports are built, by default, in /usr/ports/category/portname/work. If that takes room in /, it's because you have one of the newer single filesystem installs. It won't take any less space anywhere else.

There's a big catch for Firefox. If you have the PGO option enabled, it takes lots of space and lots of time, for very little gain.
 
As far as I know, I didn't have the PGO option enabled unless by default. I've been having an increasing amount of trouble with firefox ever since 3.6.25 (under FreeBSD - under XP there's no problem), so now I try to build with defaults since that's usually had the most QA, if any. But the cursëd thing is frankencode, patched together from 133 compilands, which is positively barking.

I'm running 8.3, and what the build does is slap a monster .core into /root, whence my desire to # su out and let it get slapped into /usr/home instead, where most of the disc space is.

But I # su out and the build immediately fails because it can't create a ./work. So I open another term and create it as root, and restart the build. Which immediately fails when it tries to delete the ./work subroot I just created!
 
There is no reason for the build to dump core, but you can easily disable those anyway with a sysctl.
 
This is related to the problems discussed in the "Firefox build fails" thread: Thread 37725. In short, the problems with installed ports need to be fixed, and then a Firefox build won't dump core.
 
Another way is to run ZFS; all your filesystems just share space from the pool. So although you'll be putting a lot of space in /, it doesn't matter as it's all just a big pool, and there's no hard limit for any one filesystem (unless you explicitly set one).
 
You could also:
  1. Use a bigger hard drive
  2. If sharing, use a bigger slice/partition
  3. Clean /usr/ports/distfiles
  4. Stop the build process and clean the dependencies which have already been built
  5. Add an external drive, format it, and link it to /usr/ports
 
Set WRKDIRPREFIX to a place with more room. The build process will use that instead of cluttering up /usr/ports/.
 
To repeat: if the build dumps core, more disk space will not fix it.
Click to expand...

It will fix the problem of the rootfs being 108% full (which may have a whole bunch of side-effects).

What I do is:
- link /tmp to /var/tmp-/
- link /root to or /home/root/

Note I use /var/tmp-/, not /var/tmp/ ... /tmp/ is supposed to be `volatile', meaning the content are deemed unimportant and susceptible to deletion at any point. /var/tmp/ is not...

Now, the first answer to this will probably be something along the lines of:
The root filesystem should be self-contained, if /var/ or /usr/ is unavailable stuff might fail
Click to expand...

I will save on electrons by responding preemptively:
This *used* to be good advice when different filesystems used to be different physical disks, but this hasn't been the typical use case in ages. Certainly not on the desktop. The changes of /usr/ failing and / still working fine are pretty small.

/usr/ is a silly filesystem anyway, the only reason it's there is because a 256K disk was full in 1972 (see: here and here).

/var/ is more useful, it does a lot of writes and tends to get corrupted a bit fasted on crashed etc. but the only case where this is a problem is when a) /var/ is completely useless and b) You need to do complex stuff with just your rootfs... Both are highly unlikely, and *if* this occurs and *if* you're competent enough to end up here, then surly you can re-create a missing /tmp/.
 
You must log in or register to reply here.
Back
Top