Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I was actually interested in running a ZFS set up but after talking to some people they advised me not to run ZFS on a system without ECC memory. Reason being, if corrupt memory would be written into your ZFS set up you won't be able to recover from it.

I'm curious about any further thoughts/experience on this.



One of you missed the point. The reason ECC is suggested with ZFS is because all of the other features (RAIDZ and checksumming in particular) don't do any good if your data gets corrupted in memory. This is true for all filesystems, but most of them don't try as hard to protect your data in the first place.


I could very well have got it wrong but the way I understand it was that in a file system such as ext4, if a file is somehow corrupted in memory and written to disk you might not be able to recover from this and the file might become useless. However, with ZFS you would lose "all" your files in the file system. Again, I might have misunderstood.


I run ZFS with ECC now, but for about 5 years I used it without ECC, and all else being equal, given the choice between ZFS without ECC, and forgoing ZFS altogether, I'd still go with ZFS. Memory errors can happen, but they seem to me to be relatively rare; I've no knowledge that I've ever suffered from one except when the DIMM was very definitely faulty (and ECC won't necessarily save you from that, though it will give early warning of the problem), and I don't think I've ever actually heard of someone's ZFS system being wiped out by one. (There appears to be a certain amount of folklore grown up around ZFS, perhaps as a result of people repeating recommendations without really knowing the justification for them, so I do appreciate it can be difficult to gauge these sort of concerns.)

On the other hand, disk electonics failures, disk controller failures, backplain failures, all do happen. Frequently. To me. (Well, more frequently than I'd like), and when they occur intermittently, these classes of failures will produce on-disk corruption, but that ZFS can withstand, even without ECC. So I would gladly take ZFS's protection against these, even at the risk of whatever it is that a memory error might produce.

Lastly, consider that if the data is important enough to warrant worrying about memory errors, it's important enough to have backups.


Example of non-ecc memory corruption and effect: http://comments.gmane.org/gmane.os.illumos.zfs/1779


Also you did misunderstand: the ECC requirement is essentially purely because if data is corrupted in memory, it can't be repaired. It's not because ZFS is somehow more susceptible to the problems of memory corruption - the FS is just obsessed with data integrity.


Wouldn't surprise me, ZFS is pretty bad at recovering from metadata corruption.


Disagree: ZFS is show stopped by unimportable pools, which currently are probably usually recoverable if someone could do the work to fix that use case (still iffy).

I've had a ZFS volume get very thoroughly trashed though by bad writes and still been able to recover data from it (back in the foolish days before ZFS-on-Linux when I had OpenSolaris in a VirtualBox VM with real disks, and something happened that randomly nuked blocks all over one of the filesystems. Interestingly: just the one FS. I had a whole bunch and others were untouched).


If metadata is corrupted to a point where pool can't be imported, you probably won't save much from it and shouldve had a backup anyway.

You might want to recover at least some files from a badly damaged FS if it is your home server with a baby photos, but would you really do that, if it was accounting of your company and not restore from a backup instead?


This slideshow has a nice summary of the basics of running a ZFS pool, and covers many common mistakes and explains them (including ECC memory): http://forums.freenas.org/index.php?threads/slideshow-explai...

I would recommend anyone new to ZFS read it if they care about the data they are storing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: