Date: Mon, 12 Mar 2001 17:09:05 -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: <20010312170905.O18351@fw.wintelcom.net> In-Reply-To: <Pine.LNX.4.21.0103121609130.31161-100000@zeppo.feral.com>; from mjacob@feral.com on Mon, Mar 12, 2001 at 04:18:41PM -0800 References: <20010312160742.L18351@fw.wintelcom.net> <Pine.LNX.4.21.0103121609130.31161-100000@zeppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Jacob <mjacob@feral.com> [010312 16:18] wrote: > > > > > 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. > > > > > > Well, if I understood your mail, you were trying to find out a way to live > > > safely with not only ordering (which is done in s/w with softupdates for > > > FreeBSD, right?- last I heard from Steve Tweedie was that he was considering > > > using tags for ordering in ext3) but also to try and live safely with data > > > that is cached on the drive electronics but not committed to media yet. > > > > > > Did I misunderstand your questions to Justin? It's quite possible as I've been > > > switching between 5 different systems I'm working on today and I'm sure that > > > things didn't committed to &my& media before things were wiped as switched > > > from one KDE desktop to another..... > > > > Your previous paragraph "Well, if I understood your mail" is what I was > > looking for. Basically I was inquiring if the hardware could/would > > support a request to perform a write-through or not lie about the > > write completing for certain tagged writes. > > There's no 'lying' here- the writes are completing. Those are "done" > operations. It just depends on the mode you've set the disk (or tape, for that > matter, which is usual) whether or not done means "on media" or "in drive > cache". These operations are so done, in fact, that if there is an error later > in putting them to media itself, there'll be all kinds of interesting toe > stubbing going on. > > What I referred to in my previous mail is setting the FUA bit in the write. > > In the SCSI-2 spec, section 9.1.6, one paragraph states, in part: > > ...For a write operation, setting FUA to one causes the direct-access > device to complete the data write to the physical medium before > completing the command.... Being able to tell the driver to do this from software would be the best. This would allow us to use writecaching for data, but force stable storage for meta-data. I think we'd also want to use this for forced data sync (fsync(2) and files opened with O_SYNC). > Does think this sounds like what you wan? Yes. > You can also force data to not be in > the drive cache as well (even when committed to media), so you can do things > like not blow your drive cache on data you don't expect to need to re-read for > a while- but this is cleverer than what is needed. This looks like an optimization that could be used for things like physio and probably any case mentioned above (B_PUSH). -- -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?20010312170905.O18351>