Hi Richard, hi Daniel, hi Roy
thanks for Your response..
Sorry for my delay, I spent a longer time ill in bed and didn't had the time to
go on in testing the system:
Am 19.06.2011 um 01:39 schrieb Richard Elling:
You're better off disabling dedup for this workload. If the dedup ratio was
On Jun 16, 2011, at 3:36 PM, Sven C. Merckens wrote:
Hi roy, Hi Dan,
many thanks for Your responses.
I am using napp-it to control the OpenSolaris-Systems
The napp-it-interface shows a dedup factor of 1.18x on System 1 and 1.16x on
System 2.
You're better off disabling dedup for this
Hi roy, Hi Dan,
many thanks for Your responses.
I am using napp-it to control the OpenSolaris-Systems
The napp-it-interface shows a dedup factor of 1.18x on System 1 and 1.16x on
System 2.
Dedup is on always (not only at the start), also compression is activated:
System 1 = compression on
On 06/16/11 15:36, Sven C. Merckens wrote:
But is the L2ARC also important while writing to the device? Because
the storeges are used most of the time only for writing data on it,
the Read-Cache (as I thought) isn´t a performance-factor... Please
correct me, if my thoughts are wrong.
if
System1 (inhouse)
SuperMicro-enclosure 2U SC825TQ
Mainboard: X8DTH-IF
1 x 1 x Quad-Core Intel Xeon E5620 processor, 2.4GHz, 12MB L3 Cache
24GB of RAM (3 x 8GB)
1 x LSISAS9211-8I (for the internal 8 drive-carriers)
1 x LSISAS9200-8E (for the JBOD)
attached is a
1 x
On Wed, Jun 15, 2011 at 07:19:05PM +0200, Roy Sigurd Karlsbakk wrote:
Dedup is known to require a LOT of memory and/or L2ARC, and 24GB isn't really
much with 34TBs of data.
The fact that your second system lacks the l2arc cache device is absolutely
your prime suspect.
--
Dan.
3G per TB would be a better ballpark estimate.
On Wed, Jun 15, 2011 at 8:17 PM, Daniel Carosone d...@geek.com.au wrote:
On Wed, Jun 15, 2011 at 07:19:05PM +0200, Roy Sigurd Karlsbakk wrote:
Dedup is known to require a LOT of memory and/or L2ARC, and 24GB isn't
really much with 34TBs of data.
