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

interesting find! I wonder what would be a good safeguard to this. I feel like just backing up your data would offer something - but a file could silently change and become corrupted in the backup too.


Hm. You could make two backups and checksum each file and safe the checksum. Then you could compare regularly file contents with the initial checksum, if there is a mismatch copy from the other backup.


Git-annex is nice for this; the fsck command will check the file against a checksum and request a new copy from other node automatically if the check fails.


You could use ZFS, then the file cannot silently become corrupted.


Yes it can. ZFS will only notice next time you scrub or read the sector.


Sure, but your ZFS pool will have redundancy, and ZFS will know which block was corrupted. This lets it recover from the error.


If the corruption occurred on disk, yes. If it occurred in memory then it will write multiple incorrect copies to disk.


This is why ECC is important. Many many people poo poo the idea that it's needed. But by not having it you have left a single vital part of the data path unprotected. And ram and disk is cheap, losing your data is not. The risk simply isn't worth it to save literally a few dollars.


That's no argument against ZFS, or backups, or any other form of redundancy. Only the insane would buy computers without ECC.




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

Search: