On 18 mrt 2010, at 10:07, Henrik Johansson wrote:
> Hello,
>
> On 17 mar 2010, at 16.22, Paul van der Zwan <paul.vanderz...@sun.com> wrote:
>
>>
>> On 16 mrt 2010, at 19:48, valrh...@gmail.com wrote:
>>
>>> Someone correct me if I'm wrong, but it could just be a coincidence. That
>>> is, perhaps the data that you copied happens to lead to a dedup ratio
>>> relative to the data that's already on there. You could test this out by
>>> copying a few gigabytes of data you know is unique (like maybe a DVD video
>>> file or something), and that should change the dedup ratio.
>>
>> The first copy of that data was unique and even dedup is switched off for
>> the entire pool so it seems a bug in the calculation of the
>> dedupratio or it used a method that is giving unexpected results.
>
> I wonder if the dedup ratio is calculated by the contents of the DDT or by
> all the data contents of the whole pool, i'we only looked at the ratio for
> datasets which had dedup on for the whole lifetime. If the former, data added
> when it's switched off will never alter the ratio (until rewritten when with
> dedup on). The source should have the answer, but i'm on mail only for a few
> weeks.
>
> It'a probably for the whole dataset, that makes the most sense, just a
> thought.
>
It looks like the ratio only gets updated when dedup is switched on and freezes
if you switch dedup off for the entire pool, like I did.
I tried to have a look at the source but it was way too complex to figure it
out in the time I had available so far.
Best regards,
Paul van der Zwan
Sun Microsystems Nederland
> Regards
>
> Henrik
> http://sparcv9.blogspot.com
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
