From owner-freebsd-current Thu Sep 9 8:45:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id 7F52D15148 for ; Thu, 9 Sep 1999 08:45:28 -0700 (PDT) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id BAA27101; Fri, 10 Sep 1999 01:44:01 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xma027094; Fri, 10 Sep 99 01:43:57 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id BAA24111; Fri, 10 Sep 1999 01:42:50 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id BAA04723; Fri, 10 Sep 1999 01:42:49 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id BAA17677; Fri, 10 Sep 1999 01:42:48 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199909091542.BAA17677@nymph.detir.qld.gov.au> To: "John W. DeBoskey" Cc: freebsd-current@freebsd.org, syssgm@detir.qld.gov.au Subject: Re: optional 'make release' speed-up patch References: <199909090404.AAA71015@bb01f39.unx.sas.com> In-Reply-To: <199909090404.AAA71015@bb01f39.unx.sas.com> from "John W. DeBoskey" at "Thu, 09 Sep 1999 00:04:39 -0400" Date: Fri, 10 Sep 1999 01:42:48 +1000 From: Stephen McKay Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 9th September 1999, "John W. DeBoskey" wrote: > The following patch to /usr/src/release/Makefile allows the >specification of the variable FASTCLEAN, which instead of doing >a recursive rm on CHROOTDIR, simply umounts/newfs/mounts. >+ -device=`df | grep '${CHROOTDIR}' | cut -f1 -d' '` && \ >+ /sbin/umount ${CHROOTDIR} && \ >+ /sbin/newfs $$device && \ >+ /sbin/mount ${CHROOTDIR} && \ >+ /bin/df ${CHROOTDIR} This is going to look like I'm putting the boot in after everyone else has already expressed a negative opinion, but I want to reinforce why this is a dangerous option, and I think a bit of unhappiness now will result in safer future contributions. I'm really not trying to be a pain. First up, destroying file systems in a makefile is a very rare event, and a pretty spectacular trick to use as a performance optimisation. Admittedly a make release is heavy stuff already, but destroying file systems is one step further than expected. Have you tested this and verified that it is a major time saving? I suspect it is not. Optimising the 10% case instead of the 90% case just increases the likelihood of bugs, and it is doubly risky to use the big guns on the small fry. The proposed code isn't very careful, and would attempt to destroy the wrong file system if, for example, I had CHROOTDIR set to /d. (Maybe I like calling file systems /a, /b, /c, etc like those crazy folks on freefall.) I doubt that it would succeed (because of checks for mounted file systems) but it would try. So, the code should verify that CHROOTDIR is a local mounted file system, and of the type you intend to make. The code runs newfs on the block device. It really should run on the character device. In a dangerous thing like on-the-fly file system destruction and creation, precision is important, even if only to instill confidence in the user when it runs. Defining FASTCLEAN to destroy a file system is a surprise unless you are intimately familiar with the makefile. That's a bear trap on the nature walk. For example, I used MACHINE all the time in my .profile until it started screwing up FreeBSD compiles. FASTCLEAN is probably somebody's favourite variable for some unimportant thing. They might never run make release, but it's lurking there for them when they do. The variable name should be more descriptive, and require that it be set to a particular value before it triggers. So, what's the upside of all this gloom? Do I really think this is the most dangerous thing I've ever seen? Well, no. I just think it is inadvisable. There is nothing stopping you from creating a script that runs make release for you. Then you can newfs your filesystem there, fully aware of the risks, and fully in control. For everyone else, the enormous rm is a useful test of the softupdates code. Most things have a silver lining if you know how to look at them. :-) Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message