Date: Thu, 11 Jun 1998 09:50:22 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: "John S. Dyson" <dyson@FreeBSD.ORG> Cc: Bruce Evans <bde@zeta.org.au>, cvs-committers@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Re: cvs commit: src/sys/ufs/ffs ffs_vnops.c Message-ID: <Pine.BSF.3.95.980611094847.29233I-100000@current1.whistle.com> In-Reply-To: <199806110351.WAA12373@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Kirk wanted the removal of the vfs_bio_awrite for testing various ideas It wil likely come back after a while. As John said. it's not much of a loss for indirect blocks. On Wed, 10 Jun 1998, John S. Dyson wrote: > Bruce Evans said: > > > Modified files: > > > sys/ufs/ffs ffs_vnops.c > > > Log: > > > Back out John's changes 1.45 -> 1.46 > > > Kirk confirms that the original semantic was what he wanted... > > > (well, a very slight difference) > > > May fix "dangling deps" panic with soft updates. > > > > > > Revision Changes Path > > > 1.50 +17 -21 src/sys/ufs/ffs/ffs_vnops.c > > > > A back out would have been +12 -17. > > > > It also seems to change the semantic to "wait for v_numoutput even in > > the soft updates case", and fix some style bugs, and break the > > optimization of using vfs_bio_awrite() instead of bawrite() for async > > writes of indirect blocks. > > > If vfs_bio_awrite optimization is broken for *just* indirect blocks, > there isn't much lossage. If the vfs_bio_awrite is broken for data > blocks, the performance loss is significant. > > -- > John | Never try to teach a pig to sing, > dyson@freebsd.org | it just makes you look stupid, > jdyson@nc.com | and it irritates the pig. > 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.3.95.980611094847.29233I-100000>