4 ms·

A person at the FreeNAS forums wrote a forum post explaining his mistaken believed that ZFS is somehow more prone to catastrophic data loss when bit flips occur

by ryao 12y ago

A person at the FreeNAS forums wrote a forum post explaining his mistaken believed that ZFS is somehow more prone to catastrophic data loss when bit flips occurred than other filesystems: https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/ https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-... The reality is that the worst case consequences for a bit flip is the complete loss of all data, regardless of the filesystem used. While the automated repair routined bundled in fsck utilities are often able to fix problems on other file systems, the problems that they do fix simply do not occur on ZFS. The kinds of problems that kill ZFS are not among those that an automated repair tool can fix. e.g. overwrite all ext4 superblocks with random data and then see if fsck.ext4 can fix it. That said, I am usually able to resuscitate a pool that another person would have considered to have been killed by a bit flip. I not only find such failure modes to be incredibly rare, but I find those that I cannot fix to be a rarity among the cases where things did in fact go wrong.

atoponce 12y ago
Indeed. I can reiterate this point. I have helped a few administrators, who initially were compiling ZFS on Linux from source, then decided to switch to the Launchpad PPA repository, and "upgrade" their userspace tools. Next thing I know, they are asking me if there is anything they can do to recover their pool. After a bit of research, and a little cleaning up, I am able to get their pool back online, with zero data loss. I have had a VERY hard time finding a situation where there was corrupted data in ZFS, and where there are ZFS pools that absolutely will not import back into full operation. In other words, it is pretty difficult to "accidentally" corrupt a ZFS pool to the point of not being able to recover your data. ECC RAM greatly minimizes the potential for a corrupted file in ZFS, but ECC RAM also greatly minimizes the potential for a corrupted file in ext4 or XFS. So long story short, I have experienced the same thing as ryao, and come to the same conclusions.

by ryao 12y ago

atoponce 12y ago

Indeed. I can reiterate this point. I have helped a few administrators, who initially were compiling ZFS on Linux from source, then decided to switch to the Launchpad PPA repository, and "upgrade" their userspace tools. Next thing I know, they are asking me if there is anything they can do to recover their pool. After a bit of research, and a little cleaning up, I am able to get their pool back online, with zero data loss. I have had a VERY hard time finding a situation where there was corrupted data in ZFS, and where there are ZFS pools that absolutely will not import back into full operation. In other words, it is pretty difficult to "accidentally" corrupt a ZFS pool to the point of not being able to recover your data. ECC RAM greatly minimizes the potential for a corrupted file in ZFS, but ECC RAM also greatly minimizes the potential for a corrupted file in ext4 or XFS. So long story short, I have experienced the same thing as ryao, and come to the same conclusions.