Date: Sun, 24 Feb 2002 21:47:04 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: "Justin T. Gibbs" <gibbs@scsiguy.com> 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 Message-ID: <38445.1014583624@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 24 Feb 2002 13:31:14 MST." <200202242031.g1OKVEI79628@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200202242031.g1OKVEI79628@aslan.scsiguy.com>, "Justin T. Gibbs" wri tes: >>>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. Well, there are two things we _may_ need here. One is a new bio-primitive "BIO_FLUSH" which pushes everything onto stable media. This could _maybe_ come handy with close(), sync(), fsync() kind of things. Second, if we want to have dependencies in the BIO queues, then we want them to be explicit and detailed, ie: submitting chains of I/O requests which the disksorts can then study and act on. Nothing we currently have in the tree can use such a feature, softupdates (and similar), journaling fs's (we have none) and databases (runs in user-space) would be the main candidates. Considering the complexity, I'm not willing to implement anything in this direction without at least one _actual_ user of the facility, _potential_ ones do not count. I'd say that the very concept at this time runs afoul of at least the first 4 "X11 commandments": (notice in particular #3) 1.Do not add new functionality unless an implementor cannot complete a real application without it. 2.It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion. 3.The only thing worse than generalizing from one example is generalizing from no examples at all. 4.If a problem is not completely understood, it is probably best to provide no solution at all. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?38445.1014583624>