From owner-freebsd-fs Mon Mar 12 15:46:21 2001 Delivered-To: freebsd-fs@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id F0CD937B718; Mon, 12 Mar 2001 15:46:11 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2CNiq126258; Mon, 12 Mar 2001 15:44:52 -0800 (PST) Date: Mon, 12 Mar 2001 15:44:52 -0800 From: Alfred Perlstein To: Matthew Jacob 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 Message-ID: <20010312154452.K18351@fw.wintelcom.net> References: <20010312152324.H18351@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Mon, Mar 12, 2001 at 03:33:37PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Matthew Jacob [010312 15:33] wrote: > > > > 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. Afaik we never depend on actually B_ORDERED'd data, at least not for filesystem consistancy (as afaik it would violate USL patents). We really don't need the SYNCHRONIZE CACHE either, basically a B_FLUSH would be nice, the problem I see is making sure it doesn't get eaten by the millions :) of OR's and AND's on the b_flags fields. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message