From owner-freebsd-hackers Sat May 20 18:45:40 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA16533 for hackers-outgoing; Sat, 20 May 1995 18:45:40 -0700 Received: from mpp.com (dialup-4-38.gw.umn.edu [128.101.96.38]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA16527 for ; Sat, 20 May 1995 18:45:37 -0700 Received: (from mpp@localhost) by mpp.com (8.6.11/8.6.9) id UAA00892; Sat, 20 May 1995 20:42:14 -0500 From: Mike Pritchard Message-Id: <199505210142.UAA00892@mpp.com> Subject: Re: kernel database files To: bde@zeta.org.au (Bruce Evans) Date: Sat, 20 May 1995 20:42:14 -0500 (CDT) Cc: hackers@FreeBSD.org In-Reply-To: <199505202023.GAA13062@godzilla.zeta.org.au> from "Bruce Evans" at May 21, 95 06:23:56 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1072 Sender: hackers-owner@FreeBSD.org Precedence: bulk > >Due to the way I name my kernels (kernel.MMDD, linked to /kernel), > >whenever I boot a new kernel for testing before linking it to > >/kernel, I wind up with a new kernel database file in /var/db. > >Booting a lot of different kernels can cause your root file system to > >start filling up, since these files are 300K+ in size. How about if > > I think the kernel database should be regenerated at every boot like > it was in 1.1. kvm_mkdb was very slow in 2.0 due to braindamaged > buffering in kvm_mkdb and/or db and braindamaged non-delayed writing > of full blocks in ufs, but Poul fixed kvm_mkdb on 1995/01/10 so it > now takes only about 1 second on a DX2/66. > > Bruce kvm_db does get run at each but, but if may not do anything since it also has some logic in it to not rewrite the file if it decides that the database matches the current kernel. Since kvm_mkdb is fast enough, maybe rc should read like: rm -f /var/db/kvm_*.db kvm_mkdb -- Mike Pritchard pritc003@maroon.tc.umn.edu "Go that way. Really fast. If something gets in your way, turn"