From owner-cvs-all@FreeBSD.ORG Sat Aug 19 13:25:44 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B8BF16A4DD; Sat, 19 Aug 2006 13:25:44 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 938B443D5E; Sat, 19 Aug 2006 13:25:41 +0000 (GMT) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 1466599C079; Sat, 19 Aug 2006 15:25:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OO6v1Pffjwko; Sat, 19 Aug 2006 15:25:37 +0200 (CEST) Received: from [192.168.2.186] (catv-50635cb6.catv.broadband.hu [80.99.92.182]) by server.t-hosting.hu (Postfix) with ESMTP id 63F7399C05C; Sat, 19 Aug 2006 15:25:37 +0200 (CEST) Message-ID: <44E71150.9080906@FreeBSD.org> Date: Sat, 19 Aug 2006 15:25:36 +0200 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Kris Kennaway References: <44E38E2F.4000005@FreeBSD.org> <44E391AD.3010402@FreeBSD.org> <44E39535.10701@FreeBSD.org> <20060816234236.3428ab08@dev.lan.Awfulhak.org> <20060817094501.GA98961@xor.obsecurity.org> <20060817084317.55ae1c08@demarc.ca.sophos.com> <20060817163848.GA27460@xor.obsecurity.org> <20060817134546.0c05e607@demarc.ca.sophos.com> <20060817222937.GA38985@xor.obsecurity.org> <44E6F4FB.3070907@FreeBSD.org> <20060819132055.GA5314@xor.obsecurity.org> In-Reply-To: <20060819132055.GA5314@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brian Somers , ports-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-ports@FreeBSD.org Subject: Re: 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 ...) X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2006 13:25:44 -0000 Kris Kennaway wrote: > On Sat, Aug 19, 2006 at 01:24:43PM +0200, G?bor K?vesd?n wrote: > >> Kris Kennaway wrote: >> >>> 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 >>> >>> >> I don't have success with mount_nullfs on 6.1/amd64 either: >> >> [root@server /jail/www/usr]# mount_nullfs /usr/ports /jail/www/usr/ports >> mount_nullfs: Operation not supported by device >> > > Presumably it is not enabled in your kernel and you do not have the > module available either (it is present on a default installation > though). I use nullfs on amd64 every day so I know it works fine. > > Kris > Ah, you're right, I found it in NOTES, but I don't see why this feature is not in the GENERIC kernel. This is a production system where I don't have modules, that's why I had the error, but imho it should be added to GENERIC as well. -- Cheers, Gabor