2 ms·

There is plenty there to read. I would rather not spend my Sunday reading that to see if I can think of something equivalent. However, you might find these page

by ryao 10y ago

There is plenty there to read. I would rather not spend my Sunday reading that to see if I can think of something equivalent. However, you might find these pages helpful: http://open-zfs.org/wiki/System_Administration http://open-zfs.org/wiki/System_Administration http://open-zfs.org/wiki/Performance_tuning http://open-zfs.org/wiki/Performance_tuning http://open-zfs.org/wiki/Hardware http://open-zfs.org/wiki/Hardware There are also mailing lists and IRC channels where you can ask questions. On freenode, there are #zfsonlinux, #openzfs, #openzfs-osx and #zfs.

specialist 10y ago
Sorry, I didn't mean for you to read it, just linked to be clear. The Jespen effort verifies the reliability claims of various persistence schemes. Independent verification, if you will.
- ryao 10y ago
  ZFS has a utility called ztest that performs stochastic testing on the core ZFS code in userspace with assertions enabled. It catches many reliability issues and is something that anyone can run. There is also the zinject framework for doing fault injection. As for independent verification, here are the top two results from searching google from my IP address for "Zfs paper reliability": http://pages.cs.wisc.edu/~kadav/zfs/zfsrel.pdf http://pages.cs.wisc.edu/~kadav/zfs/zfsrel.pdf http://research.cs.wisc.edu/adsl/Publications/zfs-corruption-fast10.pdf http://research.cs.wisc.edu/adsl/Publications/zfs-corruption... There is nothing surprising to me there. The merkle tree with good quality 256-bit checksums strongly guarantees that corruptions are detected and redundancy allows for correction. The main ways of messing up would be a buggy driver, something else in the kernel damaging the driver's data structures or hardware corrupting memory. The stochastic testing gives some protection against the first of those. I guess you could target the two things that live outside of the merkle tree (labels and ZIL blocks), but those are self checksummed and used in ways that minimize the potential for issues. Here is a summary of data integrity features that I wrote: http://open-zfs.org/w/index.php?title=System_Administration#Data_Integrity http://open-zfs.org/w/index.php?title=System_Administration#... It is possible that I missed some of the more obscure protections.

by ryao 10y ago

specialist 10y ago

Sorry, I didn't mean for you to read it, just linked to be clear. The Jespen effort verifies the reliability claims of various persistence schemes. Independent verification, if you will.

ryao 10y ago
ZFS has a utility called ztest that performs stochastic testing on the core ZFS code in userspace with assertions enabled. It catches many reliability issues and is something that anyone can run. There is also the zinject framework for doing fault injection. As for independent verification, here are the top two results from searching google from my IP address for "Zfs paper reliability": http://pages.cs.wisc.edu/~kadav/zfs/zfsrel.pdf http://pages.cs.wisc.edu/~kadav/zfs/zfsrel.pdf http://research.cs.wisc.edu/adsl/Publications/zfs-corruption-fast10.pdf http://research.cs.wisc.edu/adsl/Publications/zfs-corruption... There is nothing surprising to me there. The merkle tree with good quality 256-bit checksums strongly guarantees that corruptions are detected and redundancy allows for correction. The main ways of messing up would be a buggy driver, something else in the kernel damaging the driver's data structures or hardware corrupting memory. The stochastic testing gives some protection against the first of those. I guess you could target the two things that live outside of the merkle tree (labels and ZIL blocks), but those are self checksummed and used in ways that minimize the potential for issues. Here is a summary of data integrity features that I wrote: http://open-zfs.org/w/index.php?title=System_Administration#Data_Integrity http://open-zfs.org/w/index.php?title=System_Administration#... It is possible that I missed some of the more obscure protections.