Date: Mon, 12 Mar 2001 15:44:52 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Matthew Jacob <mjacob@feral.com> Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>, Soren Schmidt <sos@freebsd.dk>, Kevin Oberman <oberman@es.net>, 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> In-Reply-To: <Pine.LNX.4.21.0103121527390.31161-100000@zeppo.feral.com>; from mjacob@feral.com on Mon, Mar 12, 2001 at 03:33:37PM -0800 References: <20010312152324.H18351@fw.wintelcom.net> <Pine.LNX.4.21.0103121527390.31161-100000@zeppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Jacob <mjacob@feral.com> [010312 15:33] wrote: > > > > cc'd -fs and Matt. :) > > > > * Justin T. Gibbs <gibbs@scsiguy.com> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010312154452.K18351>