From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Brad Stone
For de-duplication to perform well you need to be able to fit the de-
dup table in memory. Is a good rule-of-thumb for needed RAM Size=(pool
capacity/avg block size)*270 bytes?
For de-duplication to perform well you need to be able to fit the
de-
dup table in memory. Is a good rule-of-thumb for needed RAM
Size=(pool
capacity/avg block size)*270 bytes? Or perhaps it's
Size/expected_dedup_ratio?
For now, the rule of thumb is 3G ram for every 1TB of unique
When I do the calculations, assuming 300bytes per block to be conservative,
with 128K blocks, I get 2.34G of cache (RAM, L2ARC) per Terabyte of deduped
data. But block size is dynamic, so you will need more than this.
Scott
--
This message posted from opensolaris.org
From: Roy Sigurd Karlsbakk [mailto:r...@karlsbakk.net]
For now, the rule of thumb is 3G ram for every 1TB of unique data,
including
snapshots and vdev's.
3 gigs? Last I checked it was a little more than 1GB, perhaps 2 if you
have small files.
For de-duplication to perform well you need to be able to fit the de-dup table
in memory. Is a good rule-of-thumb for needed RAM Size=(pool capacity/avg
block size)*270 bytes? Or perhaps it's Size/expected_dedup_ratio?
And if you limit de-dup to certain datasets in the pool, how would this
Folks,
I am a bit confused on the dedup relationship between the filesystem and its
pool.
The dedup property is set on a filesystem, not on the pool.
However, the dedup ratio is reported on the pool and not on the filesystem.
Why is it this way?
Thank you in advance for your help.
Regards,
On 09/23/10 15:36, Peter Taps wrote:
I am a bit confused on the dedup relationship between the filesystem and its
pool.
The dedup property is set on a filesystem, not on the pool.
Dedup is a pool wide concept, blocks from multiple filesystems
maybe deduplicated.
However, the dedup ratio is
I believe it goes a something like this -
ZPS filesystems with dedupe turned on can be thought of as hippie/socialist
filesystems, wanting to share, etc. Filesystems with dedupe turned off are
a grey Randian landscape where sharing blocks between files is seen as a
weakness/defect. They all
Hi Peter,
dedupe is pool wide. File systems can opt in or out of dedupe. So if multiple
file systems are set to dedupe, then they all benefit from using the same pool
of deduped blocks. In this way, if two files share some of the same blocks,
even if they are in different file systems, they
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Peter Taps
The dedup property is set on a filesystem, not on the pool.
However, the dedup ratio is reported on the pool and not on the
filesystem.
As with most other ZFS concepts, the
10 matches
Mail list logo
