From owner-freebsd-hackers Tue Feb 23 6:31:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id A678610EDE for ; Tue, 23 Feb 1999 06:31:11 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id GAA20620; Tue, 23 Feb 1999 06:30:44 -0800 Date: Tue, 23 Feb 1999 06:30:44 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Doug Rabson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 23 Feb 1999, Doug Rabson wrote: > On Mon, 22 Feb 1999, Matthew Jacob wrote: > > > > > > > > > Check the code paths and look for B_ASYNC getting unset. I believe this > > > > is the correct patch. > > > > > > As I said before, the reads and writes in question are not delayed writes. > > > The reason I have a problem is that the i/o queue in the driver has grown > > > to an obscene length, increasing latency to unreasonable levels. Changing > > > the order of processing delayed writes is irrelavent to this problem. > > > > This isn't a new problem. When I did driver level clustering at Sun back in > > 1990, I was regularly seeing queue lengths in excess of 1000 for a 16MB > > memory Sparc2. > > Thats a lot of memory to be using in a 16Mb box. Was the machine still > usable with this kind of i/o load? > Not really for interactive performance, no. But it did keep serving files. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message