From owner-freebsd-fs Mon Mar 12 15:34: 8 2001 Delivered-To: freebsd-fs@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E29FF37B71B; Mon, 12 Mar 2001 15:33:59 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA04673; Mon, 12 Mar 2001 15:33:40 -0800 Date: Mon, 12 Mar 2001 15:33:37 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Alfred Perlstein Cc: "Justin T. Gibbs" , Soren Schmidt , Kevin Oberman , scsi@FreeBSD.ORG, fs@FreeBSD.ORG, dillon@FreeBSD.ORG Subject: Re: Disk I/O problem in 4.3-BETA In-Reply-To: <20010312152324.H18351@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > cc'd -fs and Matt. :) > > * Justin T. Gibbs [010312 15:19] wrote: > > >All i need to know is if there's a way to look at a particular > > >struct bio/buf and determine if there's a need to write the > > >data sync. Soren claims that B_ORDERED is not the magic bit that's > > >needed, is there one? Or are we SOL on the kernel communicating the > > >need for a block to be written "right now" and not complete until > > >sync'd to the backing storage's non-volatile media? > > > > Most, if not all, of the kernel assumes that the data is committed to > > non-volatile storage when the write is notified as complete. FFS > > and softupdates could survive if they marked meta data or the first > > buffer across a dependency domain respectively as B_ORDERED assuming > > the device commits to media in the expected order, but softupdates > > doesn't do this, and FFS probably doesn't do this correctly. > > Hmm, it wouldn't be that hard to have the bwrite() functions > something with the buf that says, I'm waiting for this to complete > and it damn better be complete when i get it back. Ordered tags, I believe, just guarantee the order in which things are done. If you have caching enable, then you'd better have something else which does send a Synchronize Cache. Oh- I take it back- you don't need a separate command. You can actually set a bit in the WRITE command that forces things out to media. So, what you really need to do is set both B_ORDERED and a new B_FLUSH (say) if you want to not only guarantee a barrier between this op and ones that follow, but also force this op to go to disk. You could also do a Head of Queue tag if you want to guarantee that this op goes to disk write away (ahead of everyone else). If you need everything sync'd, you'll have to explicitly have the da driver send the SYNCHRONIZE CACHE command. > (*) > The ones that wait for completetion rather than bawrite() which > just asks for an async write. > > The only problem with this is that sometimes bwrite is used when > there's a shortage and it'd be nice to be able to take advantage > of write caching in those instances. > > Hopefully one of us will look into it one of these days. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message