<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: ECC RAM is more useful than RAID</title>
	<atom:link href="http://etbe.coker.com.au/2008/06/13/ecc-ram-vs-raid/feed/" rel="self" type="application/rss+xml" />
	<link>http://etbe.coker.com.au/2008/06/13/ecc-ram-vs-raid/</link>
	<description>Linux, politics, and other interesting things</description>
	<lastBuildDate>Wed, 08 Feb 2012 17:45:05 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: etbe</title>
		<link>http://etbe.coker.com.au/2008/06/13/ecc-ram-vs-raid/comment-page-1/#comment-14443</link>
		<dc:creator>etbe</dc:creator>
		<pubDate>Mon, 23 Jun 2008 04:36:47 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=608#comment-14443</guid>
		<description>MValdez: I am not aware of there ever being a mass-market laptop which supported ECC RAM.  I would not be surprised if there was some outrageously expensive mil-spec laptop with ECC RAM, but I would be utterly shocked if there was a laptop I could reasonably afford which has it.

BTRFS is a good thing and we can only expect other filesystems to add similar features.  It would not surprise me if checksums in filesystems became a standard feature in as little as 10 years.  :-#

ECC memory is not that expensive.  Computers supporting it often are.  If I was prepared to buy white-box machines then I would get one of those ASUS ones to which you refer.  But as I prefer name-brand machines that means Dell PowerEdge and HP XW machines - both of which are a little expensive (the PowerEdge is cheap as a base unit but extra bits are unreasonably expensive).</description>
		<content:encoded><![CDATA[<p>MValdez: I am not aware of there ever being a mass-market laptop which supported ECC RAM.  I would not be surprised if there was some outrageously expensive mil-spec laptop with ECC RAM, but I would be utterly shocked if there was a laptop I could reasonably afford which has it.</p>
<p>BTRFS is a good thing and we can only expect other filesystems to add similar features.  It would not surprise me if checksums in filesystems became a standard feature in as little as 10 years.  :-#</p>
<p>ECC memory is not that expensive.  Computers supporting it often are.  If I was prepared to buy white-box machines then I would get one of those ASUS ones to which you refer.  But as I prefer name-brand machines that means Dell PowerEdge and HP XW machines &#8211; both of which are a little expensive (the PowerEdge is cheap as a base unit but extra bits are unreasonably expensive).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MValdez</title>
		<link>http://etbe.coker.com.au/2008/06/13/ecc-ram-vs-raid/comment-page-1/#comment-14441</link>
		<dc:creator>MValdez</dc:creator>
		<pubDate>Mon, 23 Jun 2008 03:05:16 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=608#comment-14441</guid>
		<description>Hi. Good article. I have just read elsewhere that Mac OS X Server will use ZFS as file system; maybe that will push other vendors to provide also a checksumed/self-healing file system. (Too bad for its license though, we would already have ZFS in Linux).

I usually urge my clients to install ECC memory on every server and workstation. ECC memory is not really that expensive and prices keep dropping. As for motherboards, I usually get ASUS motherboards because of their support for ECC RAM (highly customizable in the BIOS), number of RAM slots and Linux compatibility. (I don&#039;t know however, if their laptops can use ECC memory; at least the EEE PC don&#039;t.)

Regards,

MValdez</description>
		<content:encoded><![CDATA[<p>Hi. Good article. I have just read elsewhere that Mac OS X Server will use ZFS as file system; maybe that will push other vendors to provide also a checksumed/self-healing file system. (Too bad for its license though, we would already have ZFS in Linux).</p>
<p>I usually urge my clients to install ECC memory on every server and workstation. ECC memory is not really that expensive and prices keep dropping. As for motherboards, I usually get ASUS motherboards because of their support for ECC RAM (highly customizable in the BIOS), number of RAM slots and Linux compatibility. (I don&#8217;t know however, if their laptops can use ECC memory; at least the EEE PC don&#8217;t.)</p>
<p>Regards,</p>
<p>MValdez</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: etbe</title>
		<link>http://etbe.coker.com.au/2008/06/13/ecc-ram-vs-raid/comment-page-1/#comment-14439</link>
		<dc:creator>etbe</dc:creator>
		<pubDate>Mon, 23 Jun 2008 00:14:12 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=608#comment-14439</guid>
		<description>http://en.wikipedia.org/wiki/PCIE

Carsten: There are some potential failure conditions that can defeat ECC RAM.  One is if a write is entirely lost (the previous data would be there with ECC intact).  I have no idea what the probability of this might be.  Also errors with more than one bit can be unrecoverable - but this is not a failure of ECC as it&#039;s better to lose data entirely (EG a SEGV of an application) than to get silent corruption.

According to the above Wikipedia page PCIe only uses a CRC.  As for filesystem corruption, if you use ZFS or BTRFS then the filesystem will checksum all data.  It seems likely that the combination of CRC on PCIe transfers and whatever checksum ZFS and BTRFS use will be less likely to break than a single CRC.

Timo: Interesting, thanks for the link.

Jon: Good point.  However if you have copies of a compressed file on two different media then it seems likely that the chance of getting good data at the end is better than a single uncompressed copy.

Ron: It&#039;s not just windows but the Windows pre-load system.  Many machines used to be sold (not sure if they still are) with an option to recover the OS install of a pre-load.  The idea is that if you messed up your machine you could go to the BIOS setup and ask the machine to reinstall Windows - among other things that saves you paying another license fee to MS.</description>
		<content:encoded><![CDATA[<p><a href="http://en.wikipedia.org/wiki/PCIE" rel="nofollow">http://en.wikipedia.org/wiki/PCIE</a></p>
<p>Carsten: There are some potential failure conditions that can defeat ECC RAM.  One is if a write is entirely lost (the previous data would be there with ECC intact).  I have no idea what the probability of this might be.  Also errors with more than one bit can be unrecoverable &#8211; but this is not a failure of ECC as it&#8217;s better to lose data entirely (EG a SEGV of an application) than to get silent corruption.</p>
<p>According to the above Wikipedia page PCIe only uses a CRC.  As for filesystem corruption, if you use ZFS or BTRFS then the filesystem will checksum all data.  It seems likely that the combination of CRC on PCIe transfers and whatever checksum ZFS and BTRFS use will be less likely to break than a single CRC.</p>
<p>Timo: Interesting, thanks for the link.</p>
<p>Jon: Good point.  However if you have copies of a compressed file on two different media then it seems likely that the chance of getting good data at the end is better than a single uncompressed copy.</p>
<p>Ron: It&#8217;s not just windows but the Windows pre-load system.  Many machines used to be sold (not sure if they still are) with an option to recover the OS install of a pre-load.  The idea is that if you messed up your machine you could go to the BIOS setup and ask the machine to reinstall Windows &#8211; among other things that saves you paying another license fee to MS.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ron</title>
		<link>http://etbe.coker.com.au/2008/06/13/ecc-ram-vs-raid/comment-page-1/#comment-14434</link>
		<dc:creator>Ron</dc:creator>
		<pubDate>Sun, 22 Jun 2008 11:41:20 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=608#comment-14434</guid>
		<description>Ha ha a womans PC magically re-installed an operating system.  Not even windows is that bad.</description>
		<content:encoded><![CDATA[<p>Ha ha a womans PC magically re-installed an operating system.  Not even windows is that bad.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon</title>
		<link>http://etbe.coker.com.au/2008/06/13/ecc-ram-vs-raid/comment-page-1/#comment-14374</link>
		<dc:creator>Jon</dc:creator>
		<pubDate>Fri, 13 Jun 2008 10:20:45 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=608#comment-14374</guid>
		<description>One disadvantage of compressing files for checksum verification is, if you have a corrupted text file (for example), often times you can rescue part of the file (or the corruption is evident and correctable by a human). A compressed file which is corrupted might not be de-compressable depending on the algorithm and the tools used, even if only a small fraction of the bits have been corrupted.</description>
		<content:encoded><![CDATA[<p>One disadvantage of compressing files for checksum verification is, if you have a corrupted text file (for example), often times you can rescue part of the file (or the corruption is evident and correctable by a human). A compressed file which is corrupted might not be de-compressable depending on the algorithm and the tools used, even if only a small fraction of the bits have been corrupted.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Timo Lindfors</title>
		<link>http://etbe.coker.com.au/2008/06/13/ecc-ram-vs-raid/comment-page-1/#comment-14371</link>
		<dc:creator>Timo Lindfors</dc:creator>
		<pubDate>Thu, 12 Jun 2008 20:44:00 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=608#comment-14371</guid>
		<description>Very thoughtful article. While debugging mysterious data corruption on an nfs server I put together a loop device that does crc checks, in case you are interested it is available at http://iki.fi/lindi/darcs/crcloop/</description>
		<content:encoded><![CDATA[<p>Very thoughtful article. While debugging mysterious data corruption on an nfs server I put together a loop device that does crc checks, in case you are interested it is available at <a href="http://iki.fi/lindi/darcs/crcloop/" rel="nofollow">http://iki.fi/lindi/darcs/crcloop/</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>

