<   Previous Post  All SSD V7000 SPC-1...
IBM to acquire Texas...  Next Post:   >

Comments (10)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 scott.fuhrman commented Permalink

For those with nodes that are already fairly busy and wanting to use RTC, any idea if we'll see updated node hardware come out this year with more CPU?

2 al_from_indiana commented Permalink

Very nice - I'm especially interested in the hot vdisk migrations between io groups. Any links to the docs for 6.4? I'm interested in testing these features with our svc nodes.

3 orbist commented Permalink

Scott, <div>&nbsp;</div> The CG8 nodes are already shipping with 6core CPUS, there are plans for various additional hardware options in the future, have a chat with your account team / get a roadmap discussion going.

4 orbist commented Permalink

Al, <div>&nbsp;</div> http://publib.boulder.ibm.com/infocenter/svc/ic/index.jsp?topic=%2Fcom.ibm.storage.svc.console.doc%2Fsvc_migratevdiskiogrpscli_42lens.html <div>&nbsp;</div> Try that, it describes the new "add/rmaccess" commands needed. <div>&nbsp;</div> I think the redbook updates where this is written in a slightly more consumable form are in the works.

5 David90 commented Permalink

Hi Barry, <div>&nbsp;</div> you speak about recent enhancements to iSCSI support that give better performance than before (as I understand), could you please tell us more about those enhancements ? <div>&nbsp;</div> Kind regards, <br /> -- <br /> david

6 orbist commented Permalink

David, <div>&nbsp;</div> Quite indepth code changes, mainly to support multi-session better, but with the same HBA being used for FCoE and iSCSI interfaces, we've worked on the driver code to improve interrupt handling for the iSCSI kernel functions, and streamlined the I/O passing between kernel and SVC code. <div>&nbsp;</div> The proof of the pudding is in the eating as they say, but certainly in the V7000 configurations, the iSCSI 10G driver can more than saturate the available HDD disk performance.

7 SkyRE commented Permalink

What plans to implement extension of existing array in v7000? <br /> For example add 2,4,.. more drives to existing RAID-10 (mdisk), or add 1,2,...more drives to existing RAID-5 (mdisk).

8 orbist commented Permalink

SkyRE - <div>&nbsp;</div> Array expansion is something on the roadmap, but as you can create a new array and add to a storage pool, there are higher priority items on the radar for the RAID team to work on. But it is something we plan to add in the future. <br />

9 Locca commented Permalink

Hi Barry, I have a V7000 cluster vith 2 IO groups running version 6.3. Just wondering If I have a pool span 2 IO groups, How does the write cache work? the extents located on IO group 0's write cache is on IO group 0 and the extents located on IO group1's write cache in on IO group 1? something like split cache?

10 orbist commented Permalink

Locca, <div>&nbsp;</div> The cache is still just 2 way - so whichever IO group owns the volume will cache I/O for that volume. If the mdisks are spread over multiple I/O groups, then when the cache destages, or reads data it will forward the I/O to the I/O group that owns the mdisks. In testing there is enough FC IOPs capability for this to not impact things, but in high bandwidth requirements its best to stick to mdisks and pools that are local to the caching I/O group.