Good points - people do need to remember that ZFS was designed for going big. IT does nothing to prevent memory corruption by design.... it was assumed (requi

Good points - people do need to remember that ZFS was designed for going big. IT does nothing to prevent memory corruption by design.... it was assumed (required?) that your server would use ECC ram. You also need to ensure you have adequate ram for various cacahing, and CPU power as well for checksum calculation, among other things. It's not a lightweight FS. (in-memory corruption is an issue with all filesysems - just somewhat more-so with ZFS because it was designed specifically to assume you had reliable ram. You want ram to store the hash cache or whatever too.... One could chuck an SSD in there for cache, if memory is a limit, that should speed things up drastically. And as with all raid-like systems - you want an appropriate number of hot-spares, cold spares, and a system that monitors it and acts appropriately, especially if you're going with huge drives on slow busses. You want regularly scheduled scrubs, not too many snapshots, probably disable atime (noatime) to speed up those scrubs, and compression probably off.... dedup I'm still on the fence about - I leave it off, I can only see specific situations where it would be truly useful (dedup+verify)