From owner-freebsd-current Fri Sep 10 12: 2: 8 1999 Delivered-To: freebsd-current@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 0F6AC15D2C for ; Fri, 10 Sep 1999 12:01:50 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id PAA28512 for ; Fri, 10 Sep 1999 15:01:49 -0400 (EDT) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA06425; Fri, 10 Sep 1999 15:01:19 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id PAA90030 for freebsd-current@freebsd.org; Fri, 10 Sep 1999 15:01:18 -0400 (EDT) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199909101901.PAA90030@bb01f39.unx.sas.com> Subject: Re: optional 'make release' speed-up patch In-Reply-To: <199909091542.BAA17677@nymph.detir.qld.gov.au> from Stephen McKay at "Sep 10, 1999 1:42:48 am" To: freebsd-current@freebsd.org Date: Fri, 10 Sep 1999 15:01:18 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, from the amount of mail I've received, I obviously do not understand the numbers from my tests, or I've not optimized my filesystems correctly. time rm -rf /snap 3214.20s real 2.29s user 51.53s system (53 minutes) time ./snapclean 20.34s real 0.88s user 2.80s system (20 seconds) My 'make release' process runs for 430 minutes, or 7 hours 20 minutes. 53 minutes represents a 12% performance increase in my environment. As one person stated, I do consider this a one-shot performance fix, but not a small edge condition fix. The 430 minutes represents: cd /usr/src && make world && cd /usr/src/release && make release Ok, maybe something is wrong with my system. /snap is located on a ccd: /dev/ccd0b 5384181 1 4953446 0% /snap with the following config: (changing ileave makes no difference) ccd0 16 none /dev/da0c /dev/da1c on the following drives: da0 at ahc0 bus 0 target 1 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) da1 at ahc0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) on the following controller: ahc0: irq 9 at device 14.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs The system is idle when rm'ing the snap directory. Top reports the following: 88247 root -6 0 416K 204K biord 0:08 1.07% 1.07% rm 88247 root -6 0 416K 204K biowr 0:08 0.73% 0.73% rm where most of the samples are biowr. If anyone knows how I can further optimize IO on this filesystem (other than using async or softupdates), please let me know. I'm at a loss as to what else I can do. Thanks! John On a side note, I'm rather suprised at the number of people that apparently 'run around' as root on their systems. One of the most repeated comments I received was using yet another environment variable that someone may already have used, and thus causing massive trauma to occur. Anyways, a modified patch follows: variable is NEWFSCLEAN and it must have the value NEWFS. For those who asked, I've actually been using this mechanism for about 3 months now. make release NEWFSCLEAN=NEWFS Index: Makefile =================================================================== RCS file: /mirror/ncvs/src/release/Makefile,v retrieving revision 1.508 diff -u -r1.508 Makefile --- Makefile 1999/09/07 20:47:42 1.508 +++ Makefile 1999/09/10 18:58:45 @@ -152,11 +152,23 @@ .endif .if make(release) .if exists(${CHROOTDIR}) +.if defined(NEWFSCLEAN) && ${NEWFSCLEAN} == "NEWFS" +# +# Simply umount/newfs/mount the partition where $CHROOTDIR resides. +# This only works if $CHROOTDIR is a separate mount point. +# + -device=`df | grep '${CHROOTDIR}' | cut -f1 -d' '` && \ + /sbin/umount ${CHROOTDIR} && \ + /sbin/newfs $$device && \ + /sbin/mount ${CHROOTDIR} && \ + /bin/df ${CHROOTDIR} +.else # The first command will fail on a handful of files that have their schg # flags set. But it greatly speeds up the next two commands. -rm -rf ${CHROOTDIR} -chflags -R noschg ${CHROOTDIR}/. -rm -rf ${CHROOTDIR} +.endif .endif -mkdir -p ${CHROOTDIR} cd ${.CURDIR}/../etc && ${MAKE} distrib-dirs DESTDIR=${CHROOTDIR} > 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