Thanks Rick for checking this. On number of LUNs, I vaguely had this in the back of my head, when we deployed our first Storwise, that was one of the reasons we built lots of metadata mirrored pairs rather than bigger arrays.
Thinking back I remember reading it was something to do with multipath and how IO queues are processed back to the storage device. The storwise we have is dual active, so only one half "owns" the LUN, so I recall it was optimal to encourage gpfs to load over controllers by having more multipath accessible devices. And then thinking how you cable up to you LSI fc adapters as well.... Simon ________________________________________ From: [email protected] [[email protected]] on behalf of Richard Welp [[email protected]] Sent: 20 May 2016 20:47 To: gpfsug main discussion list Subject: Re: [gpfsug-discuss] Flash for metadata I checked with the FS900 performance expert in Tucson, and here is what I was told: The 4KB and 512B blocks will both get equally great sub millisecond response times but 4KB can achieve a higher maximum IOPS rate. As far as # of luns, it doesn't really matter to the FS900, but the host operating system and other components in the data path can benefit from having more than 1 large lun. If we are trying to get the maximum possible iops, we typically run with at least 16 luns. I suspect with 4 luns you would get within 10% of the maximum performance. Thanks, Rick =================== Rick Welp Software Engineer Master Inventor Email: [email protected] phone: +44 0161 214 0461 IBM Systems - Manchester Lab IBM UK Limited -------------------------- From: "Marc A Kaplan" <[email protected]> To: gpfsug main discussion list <[email protected]> Date: 19/05/2016 11:00 pm Subject: Re: [gpfsug-discuss] Flash for metadata Sent by: [email protected] ________________________________ "I assume that creating several smaller LUNs on each FlashSystem in the same failure group is still preferable to one big LUN so we get more IO queues to play with?" Traditionally, more spindles, more disk arms working in parallel => better overall performance. HOWEVER Flash doesn't work that way... So it's going to depend... Perhaps some kind soul can point us to some information about this and how much it varies among today's flash based storage products. _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
