Someone can correct me if I'm not 100% accurate, but: Those features are thoroughly tested and not experimental. That said: nothing is guaranteed to keep your data safe, and if you're truly worried about it, don't use dedupe. In fact set ZFS to write multiple copies of everything. Create a ZFS pool with -o copies=2 or -o copies=3. Enable verification if you insist on dedupe, but if you're really worried about it, don't try to save space by writing less copies of the same data. The more copies you have of something, the less likely you are to lose it.
>From my understanding, the likelihood of a ZFS hash collision with SHA256 is 1 in 10^77, or 1 in 1,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000, which means writing a yotabyte or 10 of data before you're likely to see an incorrect hashing. Given that it's ZFS, not YFS, I don't think it's really an issue. If you're using consumer grade hardware, you're more likely to see problems caused by that than OI or ZFS. Your drives are more likely to read or write bad data than ZFS is likely to screw up. Likewise, using non-ECC RAM is going to cause you problems almost infinitely more often than ZFS dedup screw ups are. Personally, I have all my photos on a FS that is deduped, without verify, and haven't had any issues with the data. I'm using about 400GB of space in photos, with a dedupe ratio of 1.05. But I also back up to a spare 1TB drive once a week that I bring to work. If your biggest concern is data redundancy and reliability, don't do anything to keep less copies of it, even if that means sacrificing hard drive space. On Sun, Jan 29, 2012 at 22:48, Jan Owoc <jso...@gmail.com> wrote: > Hi, > > I'm building a home NAS so I don't care too much about performance, > but *do* care if I lose all my photos. I'm aware that ZFS had a very > extensive test suite that ensured that data is kept safe. > > Are the newer capabilities (specifically checksum=sha256, > compression=on, dedup=verify) thoroughly tested and guaranteed to keep > my data safe? Are any of the above options considered experimental or > otherwise not recommended if one cares about data integrity? The > documentation I encounter enumerates or explains the options without > going into detail about stability or reliability. > > Thanks, > Jan > > _______________________________________________ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > -- Seconds to the drop, but it seems like hours. http://www.eff.org/ <http://www.eff.org/>http://creativecommons.org/ _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
