3 ms·
With 4GB of RAM, you'd even be able to use ZFS. Does it use ECC memory? If not, you should not use ZFS. Without ECC memory, ZFS carries the nasty risk of writi
by chongli 7y ago
With 4GB of RAM, you'd even be able to use ZFS.
Does it use ECC memory? If not, you should not use ZFS. Without ECC memory, ZFS carries the nasty risk of writing good data with a bad checksum, leading to data loss which would not occur in other filesystems (those that do not try to correct errors on the fly like ZFS).
- nabla9 7y agoMost other filesystems don't do checksum at all, so you can't even discover that you have a data loss/or corruption. Only difference is that other filesystems may have better tools to rescue damaged filesystem after metadata is corrupted.
- mclehman 7y agoIn the case of a traditional filesystem, similarly unfortunate memory corruption would just affect the actual data directly. Forgoing ZFS throws out the happy path where the checksum does catch a data error and repairs it transparently. Edit: To add on to this, ZFS doesn't do parity-based repair at the checksum level. In the mentioned case (good data, bad checksum) no copy of the block will match the checksum and there will be no supposedly-good block to copy over.
- TheAceOfHearts 7y agoAs I understand it, this is just a myth. Here's a post [0] from Matthew Ahrens, one of the co-founders of ZFS who has remained active in its development: > There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error. [0] https://arstechnica.com/civis/viewtopic.php?p=26303271#p26303271 https://arstechnica.com/civis/viewtopic.php?p=26303271#p2630...
- flyinghamster 7y ago> Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). Ooooo, I hadn't heard about that one. I have one non-ECC box running ZFS where I might want to enable this. If the performance impact is negligible, it'd be worth trying.
- msiebuhr 7y agoWithout ECC memory, ZFS carries the nasty risk of writing good data with a bad checksum, leading to data loss which would not occur in other filesystems Assuming a memory error somewhere: On ZFS you'd be writing bad data with a bad checksum, which would be caught by ZFS later on. On (most) other filesystems you'd be writing bad data and no checksum, and you'd be none the wiser until garbage comes back. It's a myth that ZFS requires ECC memory; ZFS is safer when running with ECC, but without ECC it will still save your data in a lot of places where most other filesystems won't. See https://www.reddit.com/r/zfs/comments/7ng231/does_a_zfs_mirror_need_ecc/ https://www.reddit.com/r/zfs/comments/7ng231/does_a_zfs_mirr... for a bunch of links on this.
- ubercow13 7y agoOn the other hand, it carries the advantage of being able to correct bad data (or at least detect it) if it writes bad data and a good checksum, which other filesystems won't do. Seeing as the data for a check-summed block is much larger than the checksum itself, this seems like a net win as assuming a uniform probability of memory errors for each byte of memory, an error is more likely to occur in the data (though I guess it depends on the specifics of the implementation).