From owner-freebsd-scsi Sun Feb 14 10:25:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA22197 for freebsd-scsi-outgoing; Sun, 14 Feb 1999 10:25:42 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA22184 for ; Sun, 14 Feb 1999 10:25:38 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id KAA27173; Sun, 14 Feb 1999 10:25:14 -0800 Date: Sun, 14 Feb 1999 10:25:13 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Andreas Klemm cc: "Kenneth D. Merry" , ANDREAS.KLEMM.AK@bayer-ag.de, scsi@FreeBSD.ORG Subject: Re: It%s not the write cache on 3.0-STABLE and not tagged comma In-Reply-To: <19990213114641.B6068@titan.klemm.gtn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > But if write performance is poor, but actually doesn't eat up > that much CPU performance. Why is the FreeBSD machine so much > "in-responsive". It means I merely can login on a second console, > I have to wait 10-15 seconds for a login. And the execution of > commands lags lags lags. This kind of blockage is often a VM/Buffer Cache type of issue- the same problem applies in Linux. If you don't put some hysteresis into you're bdelwri queue, you end up swamping the system writing out to one spindle. This whole area of system performance, including whether or not using the maximum number of tags you can, needs to be really thought through and *metrics* used to prove or disprove cases. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message