As noted, the ratio caclulation applies over the data attempted to
dedup, not the whole pool. However, I saw a commit go by just in the
last couple of days about the dedupratio calculation being misleading,
though I didn't check the details. Presumably this will be reported
differently from the
On 18 mar 2010, at 18.38, Craig Alder wrote:
I remembered reading a post about this a couple of months back.
This post by Jeff Bonwick confirms that the dedupratio is calculated
only on the data that you've attempted to deduplicate, i.e. only the
data written whilst dedup is turned on - h
I remembered reading a post about this a couple of months back. This post by
Jeff Bonwick confirms that the dedupratio is calculated only on the data that
you've attempted to deduplicate, i.e. only the data written whilst dedup is
turned on -
http://mail.opensolaris.org/pipermail/zfs-discuss/2
On 18 mrt 2010, at 10:07, Henrik Johansson wrote:
> Hello,
>
> On 17 mar 2010, at 16.22, Paul van der Zwan 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 co
Hello,
On 17 mar 2010, at 16.22, Paul van der Zwan
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 alr
On 17 mrt 2010, at 10:56, zfs ml wrote:
> On 3/17/10 1:21 AM, Paul van der Zwan 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
On 3/17/10 1:21 AM, Paul van der Zwan 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 c
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
> gig
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
> gig
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
On Opensolaris build 134, upgraded from older versions, I have an rpool for
which I had switch on dedup for a few weeks.
After that I switched to back on.
Now it seems the dedup ratio is stuck at a value of 1.68.
Even when I copy more then 90 GB of data it still remains at 1.68.
Any ideas ?
11 matches
Mail list logo
