On 2015-12-02 07:14, Raul Miller wrote:
On Tue, Dec 1, 2015 at 5:21 PM, Tinker <[email protected]> wrote:
So your current solution is *NOT* data-safe toward "mis-write":s and
other
write errors that go unnoticed at write time.
While I agree that the probability that the writes to both disks and
to
their checksum areas would fail are really low, the "hash tree"/"100%
hash"
way of ZFS must be said to be a big enabler because it's an integrity
preservation/data safety scheme of a completely other, higher level:
Anything can fail - you need numbers describing the failure rates (and
describing the performance and resource costs of the associated
features) to make an intelligent comparison.
Raul,
At least as for me, I'd be happy to go with the merkle tree hash-based
solution even if the overhead was extremely large, like anywhere up to
80% lower IO performance would be fine with me. I would guess that that
not is the case though, I think we're talking about something more like
5-15% overhead.
I guess the choice of going with a merkle-fulldisk hash or not should be
guided by practical need rather than performance.
But I agree local configuration options within such a setup are
interesting to study, and also how the general design of such a setup
affects performance.
As for failure rates and comparison with features, did you think of
anything in particular -
What do you say of simply looking at what you need within what you do in
particular, and then look at what overhead that would imply, and act
from there?
I don't find anything particularly interesting in harddrive failure
studies such as the following, feel free to correct me if you see
anything else.
http://static.googleusercontent.com/media/research.google.com/sv//archive/disk_failures.pdf
https://www.usenix.org/legacy/events/fast07/tech/schroeder/schroeder.pdf
https://users.ece.cmu.edu/~omutlu/pub/flash-memory-failures-in-the-field-at-facebook_sigmetrics15.pdf
https://storagemojo.com/2007/02/20/everything-you-know-about-disks-is-wrong/
Best regards,
Tinker