From owner-freebsd-hackers Thu Jul 10 21:57:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA16210 for hackers-outgoing; Thu, 10 Jul 1997 21:57:08 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA16205 for ; Thu, 10 Jul 1997 21:57:05 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0wmXgg-0006q8-00; Thu, 10 Jul 1997 21:52:10 -0700 Date: Thu, 10 Jul 1997 21:52:10 -0700 (PDT) From: Tom Samplonius To: Simon Shapiro cc: FreeBSD-Hackers@freebsd.org Subject: Re: Make World Explodes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 10 Jul 1997, Simon Shapiro wrote: > > Is there is any chance your source tree is damaged? Try removing the > > files in /usr/sup, and re-running cvsup. cvsup will then check every > > file, rather than rely on the database in /usr/sup. > > DON'T TELL ME THAT :-( I do not mind re-creating the checked out version > but re-doing cvsup is a long, painful process. Errr... it isn't that bad. It isn't like you are removing every file in /usr/src or anything. It forces the client to check checksums for all files that you have with the server (actually they are probably md5 digests). It only re-transfers the files that are known to different. I did this on a 486, and it only added a half hour or so to cvsup. No big deal, but it did find some files that were old, but cvsup wasn't trasnfering because the /usr/sup database said they were up to date. Crashes during a cvsup can cause this problem. > reading and writing to disk. Performance with RAID-5 is a constant > 8.9MB/Sec writing/reading mix. RAID-0 is closer to 18-20MB/Sec. 8.9MB/s for RAID-5? Is this is a controller limitation or a drive limitation? Could the controller do better with faster drives, or more channels and drives to spread io over? > The only other problem is that if you use reboot instead of shutdown (or > maybe shutdown itself), the kernel does not wait for the ``ALLOW MEDIA > REMOVAL'' to complete before resetting the CPU. DPT uses this SCSI command > to flush and invalidate the caches. Not waiting for it to finish can leave > ``few'' buffers unwritten. ``Few'' can equal 64MB, which is unpeasant. > It takes about 21-28.5 seconds to flush the caches written by newfs on a > 4096MB file system. Not nice. > Simon > > Tom