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

Reply via email to