On Sun, 24 Jan 2010 23:34:08 -0500 nixlists <nixmli...@gmail.com> wrote:
> >> provided that the controller is configured not to write-back cache, > >> the drives are configured not to write-back cache, the FS is > >> mounted 'sync'. No softupdates. Let's not divert this to something > >> tangential and unrelated. I'll take reliability over performance. > > > > You play with RAID you lose. You play with anything other than a > > straight from OS memory to platter and you lose. Which is about > > everything these days. > > FIne then, according to you it's every single RAID controller in the > world that cannot be trusted. > > Now the simplest case: a SATA controller as found on any recent > motherboard, or a SATA add-on card, and a disk with write-back cache > turned off. What are the problems there? It goes back to what I told you off-list about never being able to know how hardware really works. You cannot trust a RAID controller because you will *NEVER* know know how it actually works internally. You cannot trust a SATA controller because you will *NEVER* know know how it actually works internally. You cannot trust a disk because you will *NEVER* know know how it actually works internally. Even in the rare instances when a disk vendor provides tools or instructions to supposedly "turn off" disk cache, the very most you can ever "know" is a change in performance, but you do *NOT* really know for certain why the change is occurring. --It could be that the cache is disabled, or it could be that the cache is partially disabled, or any other number of possibilities. Even if "you" happen to be a major corporation, have a strategic partnership with a particular hardware vendor, and through contract (NDA) can get access to the details of hardware internals, the very most you will get is a rough description. Hardware vendors have a BUSINESS REQUIREMENT of preventing *FULL* disclosure of their internal design details to prevent theft of the product/design and protect their investment in engineering costs. Even if you enter into a contract and purchase a Logic Core (aka "IP Core" --that is, raw RTL) for use in your product, there are still limitations to what you can understand through simulation and analysis. More importantly, there are significant legal limitations on revealing what you know about the logic code to the public. And of course, *HOW* you implement the logic core you purchased adds yet another layer of "unknowable" for all of your customers... --which is something your company would never reveal. As long as you keep making the wrong assumption of being able to know hardware internals, you will keep making the same mistakes about what "guarantees" are even possible at the software level. The vast majority of supposed "guarantees" made by software are complete bullshit since they are based entirely on a theory of operation (i.e. "a blind guess") for the underlying hardware. The easiest way for normal human beings to grasp the problem is ponder an acronym from the storage world; "UBER" (Undetected Bit Error Rate). If a bit error is undetected, how do you measure it? When you realize undetected bit errors occur at the very lowest levels of storage devices, you understand that all these supposed "guarantees" from higher levels are actually lies if stated as certainty. The most you could ever have is a variable degree of *ESTIMATED* accuracy. There is no certainty. There is only belief. -jon
