Date: Fri, 10 Sep 1999 01:42:48 +1000 From: Stephen McKay <syssgm@detir.qld.gov.au> To: "John W. DeBoskey" <jwd@unx.sas.com> Cc: freebsd-current@freebsd.org, syssgm@detir.qld.gov.au Subject: Re: optional 'make release' speed-up patch Message-ID: <199909091542.BAA17677@nymph.detir.qld.gov.au> In-Reply-To: <199909090404.AAA71015@bb01f39.unx.sas.com> from "John W. DeBoskey" at "Thu, 09 Sep 1999 00:04:39 -0400" References: <199909090404.AAA71015@bb01f39.unx.sas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909091542.BAA17677>