X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n6HAZae7081051 for ; Fri, 17 Jul 2009 05:35:37 -0500 X-ASG-Debug-ID: 1247826975-5d2d02a20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hattara.pcuf.fi (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9A98736BFEC for ; Fri, 17 Jul 2009 03:36:16 -0700 (PDT) Received: from hattara.pcuf.fi (hattara.pcuf.fi [194.100.34.36]) by cuda.sgi.com with ESMTP id v1GKnGNWaYWMxlpX for ; Fri, 17 Jul 2009 03:36:16 -0700 (PDT) Received: from pcuf.fi (pcuf.fi [194.100.34.1]) by hattara.pcuf.fi (Postfix) with ESMTP id 9A9531700BE for ; Fri, 17 Jul 2009 13:35:53 +0300 (EEST) Received: by pcuf.fi (Postfix, from userid 12998) id DDECD13F77D; Fri, 17 Jul 2009 13:35:52 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by pcuf.fi (Postfix) with ESMTP id C720B13F6F4 for ; Fri, 17 Jul 2009 13:35:52 +0300 (EEST) Date: Fri, 17 Jul 2009 13:35:52 +0300 (EEST) From: =?ISO-8859-15?Q?J_P=E4lve?= To: xfs@oss.sgi.com X-ASG-Orig-Subj: Write barriers and hardware RAID Subject: Write barriers and hardware RAID Message-ID: User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-pcuf-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 9A9531700BE.72662 X-pcuf-MailScanner: Found to be clean X-pcuf-MailScanner-From: xtc@pcuf.fi X-Barracuda-Connect: hattara.pcuf.fi[194.100.34.36] X-Barracuda-Start-Time: 1247826976 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.2, rules version 3.2.2.3641 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi, I'm setting up a server to provide storage for a couple of VMware ESXi servers. I'm using the latest stable Debian and I'm leaning towards using NFS with XFS. However, I'm concerned about data integrity in the event of power-out (we have UPS but they only last so long). Here are the specific questions I have: - The XFS FAQ states that with battery backup'd RAID hardware, both write barriers and individual disk cache should be turned off. However, I'm getting better benchmark results with both turned on. What I'm wondering is, will write barriers work as intended when used with hardware RAID controller (PERC 6/E)? Googling only turned up results relating to software RAID. - The XFS FAQ also states that virtualization products prevent write barriers from working correctly. Is this still the case (specifically with ESXi 3.5 and later) and is there anything that can be done about it? Does VMFS somehow work around this, or is the problem then just "out of sight, out of mind"? Bregs, JPa