From owner-freebsd-scsi Tue Jan 6 11:42:11 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA14094 for freebsd-scsi-outgoing; Tue, 6 Jan 1998 11:42:11 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA14080 for ; Tue, 6 Jan 1998 11:42:00 -0800 (PST) (envelope-from gallatin@CS.Duke.EDU) Received: from hurricane.cs.duke.edu (hurricane.cs.duke.edu [152.3.145.1]) by duke.cs.duke.edu (8.8.5/8.8.5) with ESMTP id OAA12981 for ; Tue, 6 Jan 1998 14:41:57 -0500 (EST) Received: (from gallatin@localhost) by hurricane.cs.duke.edu (8.8.4/8.7.3) id OAA17352; Tue, 6 Jan 1998 14:41:57 -0500 (EST) Date: Tue, 6 Jan 1998 14:41:57 -0500 (EST) Message-Id: <199801061941.OAA17352@hurricane.cs.duke.edu> From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-scsi@freebsd.org Subject: painfully slow crashdumps X-Mailer: VM 6.34 under 20.3 XEmacs Lucid Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We've recently begun using FreeBSD (2.2-stable) for OS research. We started out on IDE boxes, but we've just acquired a number of PII's with Adaptec 2940UW SCSI adapters and WD 'Enterprise' 4360 disks. One of the primary drawbacks to using these machines as crash-boxes is that panic()'ing and doing a crashdump takes nearly 5 minutes to complete on a 128MB machine dumping to a scsi disk (yes, less than 500K/sec). Crashdumps take less than 1 minute to complete when dumping to an IDE disk using the on-board IDE controller on these boxes. Running Bonnie on the scsi disks shows a write speed in excess of 4MB/sec. It looks like the conservative approach of dumping 1 page at a time is to blame for these slow crashdumps. As a workaround, I've hacked sddump() to use a static buffer of size N pages, and to copy N pages into this buffer before passing the buffer to the lower levels of the scsi code for writing to the disk. However, I know next to nothing about the scsi programming interface. I randomly chose N=8 (which yields a crashdump in ~50 seconds, or about 2.5MB/sec), but I'm concerned I may run across a hardware combination that cannot handle a transaction this large. Is this a valid concern? How can I determine the maximum transaction a controller/disk can handle at runtime? Thanks in advance for your advice. Oh, if anybody would like a patch to sd.c (1.95.2.5) I'd be happy to provide it. It was a 1/2 hour hack & is probably the wrong thing to do, but it sure makes our panic/reboot cycle faster which was the goal. ;-) ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590