Date: Thu, 13 Dec 2012 14:40:10 +0100 From: Stefan Esser <se@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> Subject: Re: FreeBSD for serious performance? Message-ID: <50C9DABA.1020008@freebsd.org> In-Reply-To: <alpine.BSF.2.00.1212122324230.1449@wojtek.tensor.gdynia.pl> References: <20121211204323.310760@gmx.com> <CAJ-Vmok-DtKwNW2DJ21E_UBcf%2B3CWHJ0Z8FyiNC=mycKUFNuBA@mail.gmail.com> <50C889D3.1050404@freebsd.org> <alpine.BSF.2.00.1212122324230.1449@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50C9DABA.1020008>