From owner-cvs-all Sun Feb 24 12:30:55 2002 Delivered-To: cvs-all@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 83DD637B400; Sun, 24 Feb 2002 12:30:48 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.6/8.11.5) with ESMTP id g1OKVEI79628; Sun, 24 Feb 2002 13:31:14 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200202242031.g1OKVEI79628@aslan.scsiguy.com> To: Poul-Henning Kamp Cc: mjacob@feral.com, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_cd.c scsi_da.c src/sys/dev/ata ata-disk.c In-Reply-To: Your message of "Sun, 24 Feb 2002 20:31:24 +0100." <37516.1014579084@critter.freebsd.dk> Date: Sun, 24 Feb 2002 13:31:14 -0700 From: "Justin T. Gibbs" Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >>I always assumed it would be used by softupdates to increase the speed >>of fsync operations. By using the barrier, you can commit all deps >>asynchronously in the correct order with the appropriate barriers and >>maximize the device's queue optimizations. In other words: > >Well, I talked with Kirk, and softupdates relies on the dependencies >instead. I know, and speeding up its clock in the pending removes may free up needed free space case, etc. It just seems to me that this could be simplified (and accelerated) by just queuing the stuff and relying on device ordering semantics instead. As I said, even if Kirk decides not to use it, there are other applications where this feature is useful. I don't think that FFS should be the only arbiter for such a feature. >The problem with BIO_ORDERED is that it totally makes a mess of prioritized >I/O queuing because you might conceiveably get a low-pri BIO_ORDERED which >has to flush out hi-pri stuff. It puts a barrier across which seek optimizations cannot occur, but there is no "flushing" involved. Regardless, most systems will see few ordered transactions (and even fewer from a niced process that is not allowed to schedule I/O very often) so I don't see this as a strong reason to prevent an application from using this feature to accelerate I/O. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message