Using a ramdisk for faster port compiling

[ring_zero]

Has anyone tried using a ramdisk for optimized/faster compilation of ports? I added eight GB of RAM to this machine rather whimsically, (it's so cheap now), and am trying to come up with different ways of using it. I liked the idea of a ramdisk to speed up compilation, but I have no idea where to mount it.

 

[SirDice]

Mount it anywhere you like and set WRKDIRPREFIX. See ports(7) what it does.

 

[kpa]

Mount it somewhere under /var, for example /var/ports/tmp and set the work directory for ports in /etc/make.conf like this:

WRKDIRPREFIX=/var/ports/tmp

 

[ring_zero]

Works rather well. Thanks.

 

[cabriofahrer]

Sounds interesting, but I don't understand why with the above given path in /var the work directory is moved into RAM? What am I missing?

 

[SirDice]

Sounds interesting, but I don't understand why with the above given path in /var the work directory is moved into RAM? What am I missing?

/var/ports/tmp/ is the mountpoint where the RAM disk is mounted on. But it's just an example. You can mount it anywhere you like as long as WRKDIRPREFIX points to it.

 

[DutchDaemon]

I'll give you one local example:

/etc/fstab

tmpfs			/staging	tmpfs	rw		0	0

/etc/make.conf

WRKDIRPREFIX=/staging

That's all you need.

[cmd=]df -h[/cmd]

tmpfs           9.9G    4.0k    9.9G     0%    /staging

[cmd=]ls -ld /staging[/cmd]

drwxr-xr-x  3 root  wheel  40 Jun 15 12:19 /staging

Just ran make on a test port with some dependencies to show what happens:

[cmd=]$ find /staging -type d[/cmd]

/staging
/staging/usr
/staging/usr/ports
/staging/usr/ports/misc
/staging/usr/ports/misc/unclutter
/staging/usr/ports/misc/unclutter/work
/staging/usr/ports/misc/unclutter/work/unclutter
/staging/usr/ports/devel
/staging/usr/ports/devel/imake
/staging/usr/ports/devel/imake/work
/staging/usr/ports/devel/imake/work/imake-1.0.4
/staging/usr/ports/devel/imake/work/imake-1.0.4/.deps
/staging/usr/ports/devel/gccmakedep
/staging/usr/ports/devel/gccmakedep/work
/staging/usr/ports/devel/gccmakedep/work/gccmakedep-1.0.2
/staging/usr/ports/devel/makedepend
/staging/usr/ports/devel/makedepend/work
/staging/usr/ports/devel/makedepend/work/makedepend-1.0.3
/staging/usr/ports/devel/makedepend/work/makedepend-1.0.3/tests
/staging/usr/ports/devel/makedepend/work/makedepend-1.0.3/tests/28045
/staging/usr/ports/devel/makedepend/work/makedepend-1.0.3/.deps
/staging/usr/ports/x11
/staging/usr/ports/x11/xorg-cf-files
/staging/usr/ports/x11/xorg-cf-files/work
/staging/usr/ports/x11/xorg-cf-files/work/xorg-cf-files-1.0.4

 

[wblock@]

Time a big port compile both from RAM and off disk. Reboot before each to clear filesystem cache. With buildworld, I found essentially zero difference putting /usr/obj in a tmpfs.

 

[DutchDaemon]

I like my SSD's too much ;p)

 

[wblock@]

I like my SSD's too much ;p)

That's an interesting point. Certainly those multiple builds of LibreOffice didn't do mine any good.

 

[DutchDaemon]

In fact, all of my caches (browsers, etc.) are on a tmpfs as well.

 

[sim]

This is a somewhat tangential observation/question...

Running ZFS with 8GB (total) RAM, I note that even on heavy builds (world etc), the HD light only pulses very briefly and occasionally - e.g. one single short flash every few seconds. (I can't remember what it used to be like when I used to run UFS). So, assuming there's a decent caching infrastructure in place, like ZFS's L2ARC, is there something to be said for letting the system use memory as it sees fit? Is there much to be gained by manually specifying a RAM disc these days?

sim