From owner-freebsd-stable@FreeBSD.ORG Wed Feb 27 17:12:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C620C9B1 for ; Wed, 27 Feb 2013 17:12:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A0362F76 for ; Wed, 27 Feb 2013 17:12:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 07F4AB945; Wed, 27 Feb 2013 12:12:49 -0500 (EST) From: John Baldwin To: rihad Subject: Re: mfi timeouts Date: Wed, 27 Feb 2013 11:59:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512CFF90.8080806@mail.ru> <201302261548.56253.jhb@freebsd.org> <512DA073.9090908@mail.ru> In-Reply-To: <512DA073.9090908@mail.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302271159.13424.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Feb 2013 12:12:49 -0500 (EST) Cc: freebsd-stable@freebsd.org, vince@unsane.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 17:12:49 -0000 On Wednesday, February 27, 2013 12:58:11 am rihad wrote: > Now about this part taken from here > http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html > > By issuing a dummy read operation (thus forcing a flush of data > buffers), this issue is largely averted. > > Does this mean that battery-backed cache (BBU) is effectively rendered > useless, as all write operations are forced on to the disk platters on > every interrupt? No, this is a very different level. This is forcing pending PCI DMA transactions on the PCI bus to flush by doing a read, not forcing I/O buffers to be flushed to disk. -- John Baldwin