From owner-cvs-all Sun Feb 24 11:17:11 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 7051437B423; Sun, 24 Feb 2002 11:17:01 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.6/8.11.5) with ESMTP id g1OJHXI78807; Sun, 24 Feb 2002 12:17:33 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200202241917.g1OJHXI78807@aslan.scsiguy.com> To: mjacob@feral.com Cc: Poul-Henning Kamp , 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 "Fri, 22 Feb 2002 11:15:11 PST." Date: Sun, 24 Feb 2002 12:17:33 -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 > >Umm - was this an abortive attempt to use ORDERED Tags? If so, isn't it still >of use? 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: All data blocks First indirect block B_ORDERED All the rest of the indirect blocks First directory update B_ORDERED All the rest of the directory updates Each grouping can be optimized by the drive and there is no latency incurred in the wait to start the next dependency level. In fact, the drive may pull dependent data into the write buffer while waiting for media commits of transactions before the barrier. Even if Kirk doesn't feel like using it, this feature is not inherently evil and shouldn't be removed without more general discussion. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message