From owner-cvs-all Sun Feb 24 22:18: 1 2002 Delivered-To: cvs-all@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 3316437B402; Sun, 24 Feb 2002 22:17:52 -0800 (PST) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g1P6Hmf97730; Sun, 24 Feb 2002 22:17:48 -0800 (PST) (envelope-from mjacob@feral.com) Date: Sun, 24 Feb 2002 22:17:48 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: "Justin T. Gibbs" 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: <200202241917.g1OJHXI78807@aslan.scsiguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Well, I never assumed that Softupdates would use it. I tend to agree that it ought to be useful, irrespective of whether FFS needs it. However- every modern FS or Database weenie I've ever talked to never seems really be all that interested in an on-device barrier mechanism. I think that the really old TRW commercial filesystems types from the '60s and '70s would have found it helpful (at least the ones I used to know), but the folks doing things like ext3 or GFS or Oracle don't really see it as helpful. So- in some senses, this is a neat feature but with no current customer. When you then begin to factor in the issues about multi-initiator (e.g., on a SAN) that really makes such barrier mechanisms useless since they're single host oriented. Still, it's too bad it got deepsixed with no discussion- very typical of the way this project is now run now, alas. -matt On Sun, 24 Feb 2002, Justin T. Gibbs wrote: > > > >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