Date: Sun, 24 Feb 2002 22:17:48 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: Poul-Henning Kamp <phk@FreeBSD.org>, 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 Message-ID: <Pine.BSF.4.21.0202242213060.97671-100000@beppo> In-Reply-To: <200202241917.g1OJHXI78807@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0202242213060.97671-100000>