THAT'S THE COOLEST THING I LEARNED TODAY :D
On Sat, Apr 19, 2014 at 12:15 PM, Chris Inacio <nacho...@gmail.com> wrote:
> This has been quite the interesting thread. Way back long ago when I was
> dong graduate work in microarchitecture (aka processor design) there were
> folks who wanted to put an x86 processor in a satellite. x86, especially
> at the time, was totally NOT qualified for use in space. The Pentium chip
> (way back) had this really cool feature, that a single bit flip (e.g.
> transient fault from alpha particle strike) would deadlock the processor
> cold. If the correct bit in the reservation queue got toggled.
> So why the little story: Because people who really care about their
> computation, for the longest time, didn't use x86 processors. They used
> IBM mainframe processors, SPARC chips, etc. Why? Because, at least 10
> years ago, the ALU's in x86 chips had *zero* protection. So while there
> may have been memory protection - the results of the ALU were completely
> unprotected. PowerRISC, SPARC, PA-RISC, etc. at least all had parity
> protected ALU's. Parity can't correct the calculation, but it can detect a
> single bit fault.
> If you really want to protect your data end-to-end, you likely, still need
> to buy a better class of machine. It might now be included in x86 class
> processors, but I can't find anything that says the ALU's are protected.
> The old addage, "you get what you pay for" still applies. If you're
> interested, you can read about Fujitsu's SPARC 64 data protection:
> And I know this type of technology is in things like PowerRISC chips; IBM's
> mainframe line has had ECC protected ALU's for a long time, (which I've
> never spent the time to figure out how they work.)
> On Sun, Apr 13, 2014 at 12:34 AM, Michael Newbery <newb...@gmail.com>wrote:
>> On 13/04/2014, at 12:47 pm, Rob Lewis <groble...@gmail.com> wrote:
>> I have no dog in this fight, but I wonder if possibly the late discovery
>> of the need for ECC was a factor in Apple's abandoning the ZFS project.
>> Unlikely they'd want to reengineer all their machines for it.
>> I do not know, and am therefor free to speculate :)
>> However, rumour hath it that Apple considered the patent/licence
>> situation around ZFS to be problematic. Given the current litigious
>> landscape, this was not a fight that they were willing to buy into. Note
>> that the patent problem also threatens btrfs.
>> You might discount the magnitude of the threat, but on a cost/benefit
>> analysis it looks like they walked away.
>> Likewise, some of the benefits and a lot of the emphasis of ZFS lies in
>> server space, which is not a market that Apple is playing in to any great
>> extent. It's not that ZFS doesn't have lots of benefits for client space as
>> well, but the SUN emphasis was very much on the server side (which Oracle
>> only emphasises).
>> Now, with the OpenZFS model and in particular the options ("We'll support
>> a,b and t, but not c or e") it's possible they might revisit it sometime
>> (why yes, I am an incurable optimist. Why do you ask?) but I suspect they
>> are more interested in distributed file systems a.k.a. the cloud.
>> Michael Newbery
>> "I have a soft spot for politicians---it's a bog in the west of Ireland!"
>> Dave Allen
>> You received this message because you are subscribed to the Google Groups
>> "zfs-macos" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to zfs-macos+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> You received this message because you are subscribed to a topic in the
> Google Groups "zfs-macos" group.
> To unsubscribe from this topic, visit
> To unsubscribe from this group and all its topics, send an email to
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.