Hacker News Reader

Comment by pan69 | Hacker News Reader

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.

View on HN

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?

Reply on news.ycombinator.com