From owner-freebsd-scsi Mon Mar 12 15:19:23 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id A979E37B71B for ; Mon, 12 Mar 2001 15:19:19 -0800 (PST) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f2CNJ8s42439; Mon, 12 Mar 2001 16:19:08 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200103122319.f2CNJ8s42439@aslan.scsiguy.com> To: Alfred Perlstein Cc: Soren Schmidt , Kevin Oberman , scsi@FreeBSD.ORG Subject: Re: Disk I/O problem in 4.3-BETA In-Reply-To: Your message of "Mon, 12 Mar 2001 15:10:24 PST." <20010312151024.E18351@fw.wintelcom.net> Date: Mon, 12 Mar 2001 16:19:08 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >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. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message