Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 07:56:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5QEuJ8k007228 for ; Thu, 26 Jun 2008 07:56:19 -0700 X-ASG-Debug-ID: 1214492238-4968019c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A6D31288C9C for ; Thu, 26 Jun 2008 07:57:19 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id aJZ7YB8gO7r2FaRD for ; Thu, 26 Jun 2008 07:57:19 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id A3DAAA84103; Thu, 26 Jun 2008 09:57:18 -0500 (CDT) Message-ID: <4863AE4E.5060908@sandeen.net> Date: Thu, 26 Jun 2008 09:57:18 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: David Lethe CC: Timothy Shimmin , xfs-oss , LinuxRaid , NeilBrown , jeremy@sgi.comwe X-ASG-Orig-Subj: Re: [PATCH] disable queue flag test in barrier check Subject: Re: [PATCH] disable queue flag test in barrier check References: <486307EA.7080007@sandeen.net> <48635284.3060001@sgi.com> <486398B7.50306@sandeen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1214492240 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54399 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16580 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs David Lethe wrote: > Fyi - related problem is seen with solaris & zfs when users attach them > to hardware-based RAID subsystems. The vendors had > to make firmware tweaks to address solaris's > flush-to-disk-after-all-writes. > > Not sure what you mean about non-volatile vs. volatile write cache, > however. If you want to see if write cache is enabled on a disk drive, > or > Even a logical disk on a hardware-based RAId, under Linux, then google > "mode page editor" for lots of choices. Also look up zfs write cache > raid and you'll get information that you can just as easily apply to > Linux implementations of md. I'm not so interested in whether it is enabled; I'd like to know if it is safe (to varying degrees) in the event of a power failure, and I don't think there's any way we can know that. So the administrator, if she's sure that all cached writes will hit disk even if a breaker pops, can disable barriers. If it's just a 32MB cache seagate drive plugged into the wall, you probably had better be sure barriers are enabled or you may well have a scrambled filesystem post-power-outage. -Eric