Re: [zfs-discuss] COMSTAR dropouts with dedup enabled
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 I'll revisit de-dup soon to see if that helps the issue. -Matt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] COMSTAR dropouts with dedup enabled
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 data, reads are unaffected. The easiest way for me to replicate the problem was to restore a 2GB SQL database inside a VM. The dropouts lasted anywhere from 3 seconds to a few minutes and when connectivity is restored the other LUN's (without dedup) drop out for a few seconds. 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. Does anyone know why this is happening? I've also seen the behaviour when exporting iSCSI targets with COMSTAR. I haven't had a chance to install the SSD's for L2ARC and SLOG yet so I'm unsure if that will help the issue. System specs are- Single Xeon 5620 24GB DDR3 24x 1.5TB 7200rpm LSI RAID card Thanks -Matt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] COMSTAR dropouts with dedup enabled
On Sun, Jun 13, 2010 at 6:58 PM, Matthew Anderson matth...@ihostsolutions.com.au 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 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) estimate of the memory size of the DDT in kilobytes. The most likely case is that you don't have enough memory to hold the entire dedup table in the ARC. When this happens, the host has to read entries from the main pool, which is slow. If you want to continue running with dedup, adding a L2ARC may help since the DDT can be held in the faster cache. Disabling dedup for the dataset will give you good write performance too. Be aware that destroying snapshots from this dataset (or destroying the dataset itself) is likely to create dropouts as well, since the DDT needs to be scanned to see if a block can be dereferenced. Again, adding L2ARC may help. -B -- Brandon High : bh...@freaks.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] COMSTAR dropouts with dedup enabled
On Mon, Jun 14, 2010 at 1:35 PM, Brandon High bh...@freaks.com 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) estimate of the memory size of the DDT in kilobytes. One more thing: The default block size is 8k for zvols, which means that the DDT will grow much faster than for filesystem datasets. -B -- Brandon High : bh...@freaks.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
