-Josh

This simply saved my life! When I checked my MD3000i settings I realized the some LUNs had the status below:

Read cache: Enabled
Write cache: Enabled (currently suspended)

I had to set writeCacheEnabled to FALSE before setting to TRUE. The performance changed dramatically on the fly. I had a heavy Oracle write operation going on and svctm (iostat -xm 2) dropped from 20ms to near 0ms. Bandwidth went from 79Mbps to an avg of 150Mbps. The overall application performance is now at least 10 times better.

Cheers,

Leandro Cruz

Good questions! RAID will only protect that data that is already on disk, not data that is in the cache waiting to be written to disk. The risk comes in when you are writing some changes to disk (say to a SQL DB) and only some of the blocks are written to disk, the remaining writes are still in cache. If the single controller dies, the data in cache does not get flushed to disk and the SQL DB is inconsistent/corrupt. The controllers in the DS3300 have battery-backed cache, so a power loss to the array should trigger not be an issue as the contents of the cache will be held as long as the battery can support, and written to disk once power is restored and disks are spinning. The big risk is a catastrophic failure of the controller, but in that case you probably have bigger issues to worry about (like rebuilding your RAID sets) and/or a DR situation.

In a test/dev environment, I personally see no problem with disabling cache mirroring to enable write caching. In a production environment, I would think twice before accepting the risk, make sure I have good monitoring, and argue long and hard for a second controller for proper redundancy.

I’m failing to see why you would want to enable mirrorenabled when you have no second controller?

Cheers

http://www.ibmquicklinks.com/

The IBM website is just sooo huge and the search functionality very hit or miss, but this is a good aggregation of main links.
Also, I’d recommend contacting a skilled IBM Business Partner or two when you run into issues like this, as they are usually more eager to consult customers like yourselves and help them through issues which they’ve more than likely run into multiple times in the past and may have an easy answer to based on experience. We often do this for no fee to show our value add and hopefully earn your business in the future.
While trolling the net to try and find answer may be fun at times, it’s probably not the most efficient use of your time. Let me do the trolling for you, if I don’t have the answer already : )

If the risk is unacceptable, you should add a 2nd controller (DS3300 Controller Upgrade 1726 HC3 Feature code: 4925) or accept slower-than expected writes. If you are upgrading, you may also consider upgrading the 512MB cache in each controller to 1GB (DS3000 1GB Cache Memory Upgrade Feature Code: 4838 [$929.00 each]). All available parts/upgrades for the DS3300 can be found here: http://www-01.ibm.com/cgi-bin/common/ssi/ssialias?infotype=an&subtype=ca&htmlfid=897/ENUS107-517&appname=isource&language=enus

I agree about IBM’s documentation, you can only find the info if you call it a FastT rather than DS3300.

Josh

Thanks,
Mark

1.) Have you reached the max performance of your unit and workload? That is, with your current disk type, disk count, and RAID configuration, have you reached max load with your application profile (random read, sequential write, etc.)? If so, consider changing disk type, adding disks, or changing RAID type to better match your requirements. Use the SMCLI to capture performance stats and compare what you see to industry standard published numbers for IOPS under specific workloads.

2.) Write cache could still be disabled on your dual-controller unit. Use the SMCLI to determine if write caching is suspended – this could happen with an incomplete batter learn cycle, for example.

3.) Do you have a configuration error? Perhaps Jumbo Frames are enabled on the array, but not through the rest of the architecture (network switches, servers, etc.). Poor quality switches, oversubscribed switches, incorrect flow control settings, poor quality iSCSI initiators, multi-pathing errors, etc. could all cause problems on your system.

I hope this helps – feel free to post back a reply if you have more questions and I’ll do my best to help.

Josh