From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 13 13:40:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 960882C8 for ; Thu, 13 Dec 2012 13:40:22 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm15-vm0.bullet.mail.ird.yahoo.com (nm15-vm0.bullet.mail.ird.yahoo.com [77.238.189.216]) by mx1.freebsd.org (Postfix) with ESMTP id C20118FC08 for ; Thu, 13 Dec 2012 13:40:20 +0000 (UTC) Received: from [77.238.189.231] by nm15.bullet.mail.ird.yahoo.com with NNFMP; 13 Dec 2012 13:40:19 -0000 Received: from [217.146.188.152] by tm12.bullet.mail.ird.yahoo.com with NNFMP; 13 Dec 2012 13:40:18 -0000 Received: from [127.0.0.1] by smtp110.mail.ird.yahoo.com with NNFMP; 13 Dec 2012 13:40:18 -0000 X-Yahoo-Newman-Id: 751952.63222.bm@smtp110.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: epfF7OMVM1m05MZgDXGcLRvqdgCdyJYMM14rVDVq0p9M9IE 68ubckfY_dWC_CGaCSfjCJSU3OOWnAK5rNRIWk6SXorBgb.GAU2u_20RHtIt .jDklAHEztKqNN0Pd9K59cbbJpETnC7JAtv7iA3QU0ZE5hs4J3xa6OaxBT4A A8MuMfaqmswTIk0.7lYOK95tdbogMJ5Kb6KwIcWHSyxlqWTUn7LirAziQjdH DTX8b0E7NaO.fYozBMpeeG1J5jQaDdGCdfYZ_UxfJ6EMqPMwPM.pn_LROqWs ePZURf_vggcRbCg_aa2OiB3dw_r.ZpfO.X8_GzcGR4VZUjtjbZD_Rf3GGhob eLtZ7mnWdnzPqtgYdS5GWiGMqs__eb0VZ1G7c16oaEb8DGJxIclqQdW2FekY KjS_pZ1esDPE7eJsat8Tf6eahdFnlJa5ZCe2lnHq0xvY- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.18] (se@87.158.2.148 with plain) by smtp110.mail.ird.yahoo.com with SMTP; 13 Dec 2012 05:40:18 -0800 PST Message-ID: <50C9DABA.1020008@freebsd.org> Date: Thu, 13 Dec 2012 14:40:10 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD for serious performance? References: <20121211204323.310760@gmx.com> <50C889D3.1050404@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 13:40:22 -0000 Am 12.12.2012 23:26, schrieb Wojciech Puchar: >> The cause of the low write performance is the disabled write cache. >> Enabling the write cache is unsafe on SATA drives (with or without >> NCQ), since they do not make any guarantees that nearby data is not >> lost if power fails during a disk write. It never happened to me, >> but there is a reason that SAS drives have less capacity, much lower >> BER (one to two magnitudes) and are more expensive than SATA drives. > > interface have nothing to do. Both allows you to force writes now and then. Yes and no. SATA drives could be built to the same standards as SAS drives, but with the exception of the WD Raptor they hardly ever are. SATA drives are optimized for storage density at low cost. SAS drives have completely different design targets, in general (or their higher price could not be satisfied). SATA drives have been reported to lie about the completion not only of normal writes, but also of flush commands. And with "advanced format" (4K sector) drives, data is at risk in (logical) sectors that are not even being written to. There is no technical reason that SATA drives are less reliable with regard to hardware (bit density, BER, ...) and firmware (less strict conformance testing compared to SAS drives), but there are market forces that have this effect. >> The solution to the performance problem is simple: Turn on the write >> cache. If the data is valuable, then SAS is the solution to both the > > If data is valuable, regular and well done backup practice is the only > solution. I was referring to the higher quality firmware (with verified support for TCQ) of SAS drives. There were a number of consumer grade drives that supported tags, but where data was at risk due to firmware bugs. Backups are a way to recover from loss of data. Use of devices that are magnitudes more reliable improves short-term availability of the data and reduces the risk that a recovery will be needed. Don't mix immediate availability (as required by processing requirements) with availability of a recovery path. >> would pay one developer hour. Asking Nvidia to release the confidential >> documentation for their chip-set might help, but I doubt that there is >> much interest to add support for NCQ to an obsolete chip-set, today, >> unless you pay a developer (and even then ...). > > Even without this, i've never seen properly working NVidia hardware. ANY Yes, I've also had more problems with Nvidia hardware than with most other vendors' products. I guess this is due to the market segment they target (not sure whether this still applies for their expensive GPUs targeted at high performance computing). Regards, STefan