On Nov 12, 2009, at 1:36 PM, Frank Middleton wrote:

Got some out-of-curiosity questions for the gurus if they
have time to answer:

Isn't dedupe in some ways the antithesis  of setting copies > 1?
We go to a lot of trouble to create redundancy (n-way mirroring,
raidz-n, copies=n, etc) to make things as robust as possible and
then we reduce redundancy with dedupe and compression :-).

What would be the difference in MTTDL between a scenario where
dedupe ratio is exactly two and you've set copies=2 vs. no dedupe
and copies=1?  Intuitively MTTDL would be better because of the
copies=2, but you'd lose twice the data when DL eventually happens.

The MTTDL models I've used consider any loss a complete loss.
But there are some interesting wrinkles to explore here... :-)

Similarly, if hypothetically dedupe ratio = 1.5 and you have a
two-way mirror, vs. no dedupe and a 3 disk raidz1,  which would
be more reliable? Again intuition says the mirror because there's
one less device to fail, but device failure isn't the only consideration.

In both cases it sounds like you might gain a bit in performance,
especially if the dedupe ratio is high because you don't have to
write the actual duplicated blocks on a write and on a read you
are more likely to have the data blocks in cache. Does this make
sense?

Maybe there are too many variables, but it would be so interesting
to hear of possible decision making algorithms.  A similar discussion
applies to compression, although that seems to defeat redundancy
more directly.  This analysis requires good statistical maths skills!

There are several dimensions here. But I'm not yet convinced there is
a configuration decision point to consume a more detailed analysis.
In other words, if you could decide between two or more possible
configurations, what would you wish to consider to improve the
outcome?  Thoughts?
 -- richard


_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to