From owner-freebsd-scsi Mon Mar 12 16:19:54 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id A38E937B718; Mon, 12 Mar 2001 16:19:47 -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 QAA04885; Mon, 12 Mar 2001 16:18:44 -0800 Date: Mon, 12 Mar 2001 16:18:41 -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: <20010312160742.L18351@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > 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.... Does think this sounds like what you wan? 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. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message