<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" >HI</div>
<div dir="ltr" > </div>
<div dir="ltr" >Just want to add 2 things</div>
<div dir="ltr" > </div>
<div dir="ltr" >+1 to have more than 1 copy of Metadata</div>
<div dir="ltr" > </div>
<div dir="ltr" >The full stride write is important as repetitively been stated here. However there are implementations that have successfully reduced this (IBM FlashCore comes to mind). On the last London UG I presented different storage and blocksizes and the impact on those. I believe the presentation might be on the UG web page.</div>
<div dir="ltr" > </div>
<div dir="ltr" >+100 test it in your setup/workload</div>
<div dir="ltr" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" ><div style="font-size: 12pt; font-weight: bold; font-family: sans-serif; color: #7C7C5F;" ><font size="3" face="Arial" >--<br>Ystävällisin terveisin / Kind regards / Saludos cordiales / Salutations</font><br><font size="3" face="Arial" >Luis Bolinches</font><br><font size="3" face="Arial" >Consultant IT Specialist</font><br><font size="3" face="Arial" >Mobile Phone: +358503112585</font><br><a href="https://www.youracclaim.com/user/luis-bolinches" rel="noopener" target="_blank"><b><font size="3" face="Arial" >https://www.youracclaim.com/user/luis-bolinches</font></b></a><br><br><b><font size="3" face="Arial" color="#7C7C5F" >"If you always give you will always have" -- Anonymous</font></b></div>
<div style="font-size: 8pt; font-family: sans-serif; margin-top: 10px;" ><div> </div></div></div></div></div></div>
<div dir="ltr" > </div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: "Achim Rehor" <Achim.Rehor@de.ibm.com><br>Sent by: gpfsug-discuss-bounces@spectrumscale.org<br>To: "gpfsug main discussion list" <gpfsug-discuss@spectrumscale.org><br>Cc:<br>Subject: Re: [gpfsug-discuss] RAID type for system pool<br>Date: Thu, Sep 6, 2018 11:16 AM<br> <br><!--Notes ACF
<meta http-equiv="content-type" content="text/html; charset=utf8" >-->Hi Kevin,
<div>as you already pointed out, having a RAID stripe size (or a multiple of it) not matching GPFS blocksize, is a bad idea. Every write would cause a read-modify-write operation to keep the parity.</div>
<div>So for data LUNs RAID5 with 4+P or 8+P is fully ok.</div>
<div>For metadata, if you are keen on performance, I would stay with RAID1, or even RAID0, so you aren\u2019t affected by possible RAID rebuild performance drops.<br>
<div>Regards, Achim</div>
<div> </div>
<div><br>Am 05.09.2018 um 17:35 schrieb Buterbaugh, Kevin L <<a href="mailto:Kevin.Buterbaugh@Vanderbilt.Edu" target="_blank">Kevin.Buterbaugh@Vanderbilt.Edu</a>>:<br> </div>
<blockquote type="cite" ><div><!--Notes ACF
<meta http-equiv="Content-Type" content="text/html; charset=utf8" >-->Hi All,
<div> </div>
<div>We are in the process of finalizing the purchase of some new storage arrays (so no sales people who might be monitoring this list need contact me) to life-cycle some older hardware. One of the things we are considering is the purchase of some new SSD\u2019s for our \u201c/home\u201d filesystem and I have a question or two related to that.</div>
<div> </div>
<div>Currently, the existing home filesystem has it\u2019s metadata on SSD\u2019s \u2026 two RAID 1 mirrors and metadata replication set to two. However, the filesystem itself is old enough that it uses 512 byte inodes. We have analyzed our users files and know that if we create a new filesystem with 4K inodes that a very significant portion of the files would now have their _data_ stored in the inode as well due to the files being 3.5K or smaller (currently all data is on spinning HD RAID 1 mirrors).</div>
<div> </div>
<div>Of course, if we increase the size of the inodes by a factor of 8 then we also need 8 times as much space to store those inodes. Given that Enterprise class SSDs are still very expensive and our budget is not unlimited, we\u2019re trying to get the best bang for the buck.</div>
<div> </div>
<div>We have always - even back in the day when our metadata was on spinning disk and not SSD - used RAID 1 mirrors and metadata replication of two. However, we are wondering if it might be possible to switch to RAID 5? Specifically, what we are considering doing is buying 8 new SSDs and creating two 3+1P RAID 5 LUNs (metadata replication would stay at two). That would give us 50% more usable space than if we configured those same 8 drives as four RAID 1 mirrors.</div>
<div> </div>
<div>Unfortunately, unless I\u2019m misunderstanding something, mean that the RAID stripe size and the GPFS block size could not match. Therefore, even though we don\u2019t need the space, would we be much better off to buy 10 SSDs and create two 4+1P RAID 5 LUNs?</div>
<div> </div>
<div>I\u2019ve searched the mailing list archives and scanned the DeveloperWorks wiki and even glanced at the GPFS documentation and haven\u2019t found anything that says \u201cbad idea, Kevin\u201d\u2026 ;-)</div>
<div> </div>
<div>Expanding on this further \u2026 if we just present those two RAID 5 LUNs to GPFS as NSDs then we can only have two NSD servers as primary for them. So another thing we\u2019re considering is to take those RAID 5 LUNs and further sub-divide them into a total of 8 logical volumes, each of which could be a GPFS NSD and therefore would allow us to have each of our 8 NSD servers be primary for one of them. Even worse idea?!? Good idea?</div>
<div> </div>
<div>Anybody have any better ideas??? ;-)</div>
<div> </div>
<div>Oh, and currently we\u2019re on GPFS 4.2.3-10, but are also planning on moving to GPFS 5.0.1-x before creating the new filesystem.</div>
<div> </div>
<div>Thanks much\u2026</div>
<div> </div>
<div><div><div>\u2014</div>
<div>Kevin Buterbaugh - Senior System Administrator</div>
<div>Vanderbilt University - Advanced Computing Center for Research and Education</div>
<div><a href="mailto:Kevin.Buterbaugh@vanderbilt.edu" target="_blank">Kevin.Buterbaugh@vanderbilt.edu</a> - (615)875-9633</div>
<div> </div></div></div></div></blockquote></div>
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></div></blockquote>
<div dir="ltr" > </div></div><BR>
Ellei edellä ole toisin mainittu: / Unless stated otherwise above:<BR>
Oy IBM Finland Ab<BR>
PL 265, 00101 Helsinki, Finland<BR>
Business ID, Y-tunnus: 0195876-3 <BR>
Registered in Finland<BR>
<BR>