Thanks Brandon,
This system has 24GB of RAM and currently no L2ARC. The total de duplicated
data was about 250GB so I wouldn't have thought I would be out of RAM, I've
removed the LUN for the time being so I can't get the DDR size at the moment. I
have some X25-E's to go in as L2ARC and SLOG so
On Mon, Jun 14, 2010 at 1:35 PM, Brandon High wrote:
> How much memory do you have, and how big is the DDT? You can get the
> DDT size with 'zdb -DD'. The total count is the sum of duplicate and
> unique entries. Each entry uses ~ 250 bytes per entry, so the count
> divided by 4 is a (very rough)
On Sun, Jun 13, 2010 at 6:58 PM, Matthew Anderson
wrote:
> The problem didn’t seem to occur with only a small amount of data on the LUN
> (<50GB) and happened more frequently as the LUN filled up. I’ve since moved
> all data to non-dedup LUN’s and I haven’t seen a dropout for over a month.
How mu
Hi All,
I currently use b134 and COMSTAR to deploy SRP targets for virtual machine
storage (VMware ESXi4) and have run into some unusual behaviour when dedup is
enabled for a particular LUN. The target seems to lock up (ESX reports it as
unavailable) when writing large amount or overwriting dat
