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: <SEAGATE ST34572W 0784> 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: <SEAGATE ST34572W 0784> 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: <Adaptec 2940 Ultra SCSI adapter> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
