nullfs performance (Re: cvs commit: ports/Mk bsd.emacs.mk
bsd.gnome.mk bsd.mail.mk bsd.openssl.mk bsd.port.mk
bsd.port.subdir.mk bsd.python.mk bsd.ruby.mk bsd.scons.mk
ports/Tools/scripts security-check.awk
ports/databases/p5-DBD-Oracle Makefile
ports/databases/p5-sqlrelay ...)
Kris Kennaway
kris at obsecurity.org
Thu Aug 17 22:29:39 UTC 2006
On Thu, Aug 17, 2006 at 01:45:46PM -0700, Brian Somers wrote:
> I guess the missing info might be that things get indirected somewhat.
>
> We check out code into /some/deep/directory/tree. Then, to protect
> against the 80 character path limitation, we create /tmp/bld.XXXXX/
> and create a scratch -> /tmp/bld.XXXXX symlink in
> /some/deep/directory/tree.
Hmm, could be due to the indirecting I guess...you should be able to
test that pretty easily.
> We then do various things like:
>
> mount -t nullfs /some/deep/directory/tree/src scratch/build/src
> mount -t nullfs /some/deep/directory/tree/obj scratch/build/obj
> mount -t devfs devfs scratch/dev
> mount -t procfs procfs scratch/proc
>
> and do a "OBJDIRPREFIX=/build/obj chroot scratch make -C /build/src".
>
> Oh, and errum, we've got debug.mpsafenet="0" in /boot/loader.conf -
> which is a remnant of when we were using 5.4 and the races in the
> socket code killed our application under load.
>
> Does the nullfs code path hit the network stack??
No.
Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-ports/attachments/20060817/a64dc1dc/attachment.pgp
More information about the cvs-ports
mailing list