I'm pretty sure that the X86 architecture has had ALU error correction for 
a while now.  I know my AMD X2s had L1 and L2 ECC, and I think the ALU was 
protected (though I wouldn't swear to that).  However, looking at an Intel 
white paper on the Xeon E7 family reliability features it says: "E7 family 
provides internal on-die error protection to protect processor registers 
from transient faults, and enables dynamic processor sparing and migration 
in the case of a failing processor."  In fact the over all architecture 
looks like it robustness was a top priority concern.  If you'd like to read 
the paper you can find it here:

On Saturday, April 19, 2014 at 10:15:24 AM UTC-6, Chris 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 < 
> <javascript:>> wrote:
>> On 13/04/2014, at 12:47 pm, Rob Lewis < <javascript:>> 
>> 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 <javascript:>.
>> For more options, visit


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 
For more options, visit

Reply via email to