Supporting Spectrum Virtualize

Hello friends! I hope all is well. This week I want to take a brief hiatus from performance and software to bring up a topic that is becoming increasingly important as people move towards the Storwize Gen3 and Flashsystem 9100 hardware. These hardware platforms premiered support for the IBM FlashCore Modules (FCM). Just like with the FS900 AE3 , these flash modules do hardware compression at the drive level. This makes them economical and exciting because you get a lot of extra flash space for your money. However, it is vitally important you think before you provision. Lets start by taking a look at how capacity looks in the dashboard in the GUI: Here we see the system has 21.42TB of physical capacity. However, if we go to create a volume we can create up to 99TB: This is where things get dangerous. If we check the lsarray output for the RAID set we see: IBM_FlashSystem:fab3:superuser>lsarray 0 | grep capacity capacity 99.1TB physical_capacity 21.42TB physical_free_ca

Hello friends. After last week's post I got a lot of questions about the software stack diagram and so instead of doing a troubleshooting post I want to take a step back and just explain the diagram and in general how IBM Spectrum Virtualize software works. To start, lets take a look at the diagram: The software is comprised of several 'layers'. From top down we have a SCSI target, Replication, Upper Cache, Flashcopy, Mirroring, Thin Provisioning, Compression, Data Reduction Pool, Lower Cache, Virtualization, RAID, and SCSI Initiator that comprise most of our i/o stack. It is important to note, is this diagram is somewhat incomplete. The truth is that just after the SCSI Target, before the lower cache, and between every component under the lower cache there is a forwarding layer which I will explain in more detail a bit later in this post. SCSI Target This section of the software decodes SCSI commands that are received by the hosts and manages the IT Nexus that i

Hello friends!  Many IBM Spectrum Virtualize users have been using tools like Spectrum Control or Storage Insights to monitor their storage systems for a while now. However, we see a lot of support cases regarding performance that come with very little information outside of 'a performance problem exists.' So this week, I want to share the methodology I use to troubleshoot performance for a specific volume (or volumes tied to a specific host). Please note, this blog will assume that you have Spectrum Control or Storage Insights Pro to be able to check the detailed performance data support gets in a snap. The first step: The first step in troubleshooting any problem is acknowledging that there is one. More importantly, defining what the problem is. The information that is vital to know is: When did the problem surface? Explicitly note the date and time. What was impacted? List off specific applications or hosts and then identify their volumes. Why is it important? Is

First a quick introduction to flash hardware: Flash storage (solid state drives, flash cards, flash modules, etc.) is organized into NAND dice. These are made up of planes which are made up of blocks which are made up of pages. Pages are then made up of "words". In the flash products I typically work with, there are typically 256 pages per block, 1024 blocks per plane, and 2 planes per die. When a flash page needs to be overwritten due to changes in the data, the page is not simply overwritten. Instead what takes place is a read modify write... that is to say the original page (to be changed) is read, the changed data is calculated and the result is then written to a new page. The original page is then marked as garbage: When enough pages in a block are marked as garbage, a process called garbage collection then moves the valid pages in the block to another block and erases their original block. All flash drives are over-provisioned - or given more than the