From owner-freebsd-hackers  Mon Feb 22  1:32:33 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
	by hub.freebsd.org (Postfix) with ESMTP id EE1BF119E8
	for <freebsd-hackers@freebsd.org>; Mon, 22 Feb 1999 01:32:31 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id BAA29386;
	Mon, 22 Feb 1999 01:32:25 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 22 Feb 1999 01:32:25 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199902220932.BAA29386@apollo.backplane.com>
To: Doug Rabson <dfr@nlsystems.com>
Cc: Terry Lambert <tlambert@primenet.com>,
	freebsd-hackers@freebsd.org
Subject: Re: Panic in FFS/4.0 as of yesterday
References:  <Pine.BSF.4.05.9902220915100.82049-100000@herring.nlsystems.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    I don't think B_EXPIDITE could ever be made to work well.  Why not limit
    the number of async I/O write operations allowed to be in-progress at any 
    given moment for ops run by the syncer, swapper, or flushdirtybufs?.  
    Either on a vnode-by-vnode or a mount-by-mount basis?  I do a poor-man's 
    version of this for the swapper.  At least then the hacks would be 
    concentrated together rather then strewn all over the codebase.   The
    write queueing problem seems to be quite general in nature, which means
    that the solution should not be to have to hack each and every device
    that might do I/O ( aka UFS in this case ).

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message