From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 14:07:37 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDC6616A40F for ; Fri, 29 Sep 2006 14:07:37 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF2BC43D64 for ; Fri, 29 Sep 2006 14:07:21 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so258830uge for ; Fri, 29 Sep 2006 07:07:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fdkqm3NIq/++LNsGA9DwoHEZUKLv3ruQPmJMadodtbdIur3u5dJtfxTsN7BHrS7Vipxv9eeFmRLXf2LmXOgSKin3QiZk/2omkUraneYcEAVTawVP8mlABhqUOAto4fDQG4DwefqrZo8TboO53vj6C4lT9cfqRgnSP+jWmM/ZZ8U= Received: by 10.67.119.5 with SMTP id w5mr68615ugm; Fri, 29 Sep 2006 07:07:20 -0700 (PDT) Received: by 10.70.118.3 with HTTP; Fri, 29 Sep 2006 07:07:19 -0700 (PDT) Message-ID: <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> Date: Fri, 29 Sep 2006 09:07:19 -0500 From: Astrodog To: "Robert Watson" In-Reply-To: <20060929144738.W70454@fledge.watson.org> MIME-Version: 1.0 References: <20060929141709.E70454@fledge.watson.org> <20060929134332.GD4776@rambler-co.ru> <20060929144738.W70454@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 14:07:38 -0000 On 9/29/06, Robert Watson wrote: > > > On Fri, 29 Sep 2006, Ruslan Ermilov wrote: > > > The necessity to run rpc.lockd is documented in the build(7) manpage. > > Quote: > > I think this is a bad idea. rpc.lockd is one of the most fragile and > largely > broken pieces of the operating system. Arguably we shouldn't even be > shipping > it. Making it required for installworld is asking for trouble. > > > : installworld Install everything built by a preceding buildworld > step > > : into the directory hierarchy pointed to by make(1) > vari- > > : able DESTDIR. > > : > > : If installing onto an NFS file system, make sure that > > : rpc.lockd(8) is running on both client and > server. See > > : rc.conf(5) on how to make it start at boot time. > > > >> I've noticed an increasing intolerance in our tools for system install > and > >> maintenance to locking not being implemented over the past few > years. I no > >> longer get working cron on boxes with neither rpc.lockd nor local > locking > >> enabled, for example. Installworld represents a bigger problem, since > I > >> don't want to have to depend on a completely working rpc chain in order > to > >> installworld, nor depend on running in what would effectively be > multiuser > >> mode. Surely there's a better fix for this than adding lockf use? > >> > > I don't know of a better fix. Another approach is that mentioned in the > > commit log and used by NetBSD. I tried it, and it was very fragile -- > it > > could easily leave the temporary file around, and that would stuck > forever > > another instances. > > > > The problem at hand is that multiple instances of install-info(1) are > > attempting to write to the ${DESTDIR}/usr/share/info/dir file. If you > have a > > better idea, don't hesitate to let me know. I'd very much like to get > rid > > of that as well. > > The basic problem here is that install-info doesn't support parallelism. > Sounds like we just need to accept that and therefore accept that we don't > support doing installworld with the -j argument. A middle-ground solution > would be to only use lockf if -j is used. I'd be concerned that with this approach, we could see some rather hard to diagnose problems come up if rpc.lockd broke silently during the install, but the install continued. Personally, I find it much, much more important to be able to do an installworld from a "real" single user mode via NFS, than it is to support -j. I don't think I've ever had a circumstance where I really needed make installworld to finish quickly. Besides, if there's significant use of locks in installworld, -j doesn't get a whole lot of performance gain anyway. Another thought here, is that in my experience, installworld is disk, or network I/O bound, not CPU... Under those circumstances, we may find that there's reduced performance with -j anyway, in which case there's no reason to support it that I can see. For what its worth.... I'd go with just stopping support for -j in installworld, even if things are CPU bound. --- Harrison Grundy