Jim Salter

602 points
Jim Salter
West Columbia

I'm a mercenary systems administrator located in Columbia, SC. My first real hands-on experience with open source software was running Apache on FreeBSD webservers in the late 90s and early 2000s. Since then, I moved on to Samba, BIND, qmail, postfix, and anything and everything else that grabbed my attention. I currently support Windows, FreeBSD, Debian, and Ubuntu workstations and servers doing just about everything that you can possibly do with any or all of them. RAH said it best - specialization is for insects!

Authored Content

Avoiding data disasters with Sanoid

Sanoid helps to recover from what I like to call "Humpty Level Events." In other words, it can help you put Humpty Dumpty back together again, on ZFS filesystems. Humpty…

Authored Comments

In real life, I have seen *thousands* of CSUM errors on a single drive, on several occasions. I've similarly seen large scale corruption on drives without ZFS. Usually it's the cabling... but not always; and zfs catches it whether it's the cabling or the drive.

This comes up a lot.

* hdd hardware checksums are ECC - extremely weak, and very prone to more corruption than they can repair or even outright collision (bits flipped in such a way that the corrupted block passes its checksum). ZFS does not use ECC; it uses much stronger cryptographic hashes with very VERY low probability of hash collision, and uses parity or redundancy to repair any corrupted blocks found.

* hdd hardware checksums cannot detect errors introduced by the hdd onboard controller, by the SATA/SAS/SCSI cabling (one of the most common sources of error!), by the SATA/SAS/SCSI controller, or by bit flips in RAM during the read. ZFS checksumming can catch all of those, since it takes place in software.