On a completely unrelated note, I'm glad I came up with rules to redirect
all smtpd related mails to my phone ... smart idea ... :-)
Gilles
On Mon, Jan 25, 2010 at 11:20:24AM -0800, J.C. Roberts wrote:
> 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
>
--
Gilles Chehade
freelance developer/sysadmin/consultant
http://www.poolp.org
