<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1256">
<style type="text/css">
<!--
html
{font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"}
-->
</style><style>
<!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast
{margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%}
-->
</style>
</head>
<body dir="ltr">
<style type="text/css">
<!--
html
{font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"}
-->
</style><style>
<!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast
{margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%}
-->
</style><span style="font-family:Arial">Hi
Scott, <br>
<br>
We are considering running zfs backed lustre and the factor of 10ish performance hit you see worries me. I know zfs can splurge bits of files all over the place by design. The oracle docs do recommend scrubbing the volumes and keeping usage below 80% for maintenance
and performance reasons, I'm going to call it 'defrag' but I'm sure someone who knows better will probably correct me as to why it is not the same.
<br>
So are these performance issues after scubbing and is it possible to scrub online - I.e. some reasonable level of performance is maintained while the scrub happens?<br>
Resilvering is also recommended. Not sure if that is for performance reasons.<br>
<br>
<a href="http://docs.oracle.com/cd/E23824_01/html/821-1448/zfspools-4.html">http://docs.oracle.com/cd/E23824_01/html/821-1448/zfspools-4.html</a><br>
<br>
<br>
<br>
Sent from my HTC Desire C on Three<br>
<br>
<div id="htc_header" style="">----- Reply message -----<br>
From: "Scott Nolin" <scott.nolin@ssec.wisc.edu><br>
To: "Anjana Kar" <kar@psc.edu>, "lustre-discuss@lists.lustre.org" <lustre-discuss@lists.lustre.org><br>
Subject: [Lustre-discuss] number of inodes in zfs MDT<br>
Date: Fri, Jun 6, 2014 3:23 AM<br>
<br>
</div>
</span><br>
<br>
<div>
<div dir="ltr" style="font-family:'Calibri','Segoe UI','Meiryo','Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','sans-serif'; font-size:12pt">
<div>Looking at some of our existing zfs filesystems, we have a couple with zfs mdts
</div>
<div><br>
</div>
<div>One has 103M inodes and uses 152G of MDT space, another 12M and 19G. I’d plan for less than that I guess as Mr. Dilger suggests. It all depends on your expected average file size and number of files for what will work.</div>
<div><br>
</div>
<div>We have run into some unpleasant surprises with zfs for the MDT, I believe mostly documented in bug reports, or at least hinted at.</div>
<div><br>
</div>
<div>A serious issue we have is performance of the zfs arc cache over time. This is something we didn’t see in early testing, but with enough use it grinds things to a crawl. I believe this may be addressed in the newer version of ZFS, which we’re hopefully
awaiting.</div>
<div><br>
</div>
<div>Another thing we’ve seen, which is mysterious to me is this it appears hat as the MDT begins to fill up file create rates go down. We don’t really have a strong handle on this (not enough for a bug report I think), but we see this:</div>
<div><br>
</div>
<ol style="padding-top:0px; padding-bottom:0px; margin-top:0px; margin-bottom:0px; list-style-type:decimal">
<li style="color:rgb(0,0,0); font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size:16px">
<div>The aforementioned 104M inode / 152GB MDT system has 4 SAS drives raid10. On initial testing file creates were about 2500 to 3000 IOPs per second. Follow up testing in it’s current state (about half full..) shows them at about 500 IOPs now, but with a
few iterations of mdtest those IOPs plummet quickly to unbearable levels (like 30…).</div>
</li><li style="color:rgb(0,0,0); font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size:16px">
<div>We took a snapshot of the filesystem and sent it to the backup MDS, this time with the MDT built on 4 SAS drives in a raid0 - really not for performance so much as “extra headroom” if that makes any sense. Testing this the IOPs started higher, at maybe
800 or 1000 (this is from memory, I don’t have my data in front of me). That initial faster speed could just be writing to 4 spindles I suppose, but surprising to me, the performance degraded at a slower rate. It took much longer to get painfully slow. It
still got there. The performance didn’t degrade at the same rate if that makes sense - the same number of writes on the smaller/slower mdt degraded the performance more quickly. My guess is that had something to do with the total space available. Who knows. I
believe restarting lustre (and certainly rebooting) ‘resets the clock’ on the file create performance degradation.</div>
</li></ol>
<div style="color:rgb(0,0,0); font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size:16px">
<br>
</div>
<div style="color:rgb(0,0,0); font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size:16px">
For that problem we’re just going to try adding 4 SSD’s, but it’s an ugly problem. Also are once again hopeful new zfs version addresses it.</div>
<div style="color:rgb(0,0,0); font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size:16px">
<br>
</div>
<div style="color:rgb(0,0,0); font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size:16px">
And finally, we’ve got a real concern with snapshot backups of the MDT that my colleague posted about - the problem we see manifests in essentially a read-only recovered file system, so it’s a concern and not quite terrifying.</div>
<div style="color:rgb(0,0,0); font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size:16px">
<br>
</div>
<div style="color:rgb(0,0,0); font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size:16px">
All in all, the next lustre file system we bring up (in a couple weeks) we are very strongly considering going with ldiskfs for the MDT this time.</div>
<div style="color:rgb(0,0,0); font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size:16px">
<br>
</div>
<div style="color:rgb(0,0,0); font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size:16px">
Scott</div>
<div style="color:rgb(0,0,0); font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size:16px">
<br>
</div>
<div style="color:rgb(0,0,0); font-family:"Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size:16px">
<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div style="padding-top:5px; border-top-color:rgb(229,229,229); border-top-width:1px; border-top-style:solid">
<div><font face=" 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif'" style="line-height:15pt; letter-spacing:0.02em; font-family:"Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size:12pt"><b>From:</b> <a href="mailto:kar@psc.edu" target="_parent">Anjana
Kar</a><br>
<b>Sent:</b> ýTuesdayý, ýJuneý ý3ý, ý2014 ý7ý:ý38ý ýPM<br>
<b>To:</b> <a href="mailto:lustre-discuss@lists.lustre.org" target="_parent">lustre-discuss@lists.lustre.org</a></font></div>
</div>
<div><br>
</div>
<div dir="">
<div id="readingPaneBodyContent">Is there a way to set the number of inodes for zfs MDT?<br>
<br>
I've tried using --mkfsoptions="-N value" mentioned in lustre 2.0 <br>
manual, but it<br>
fails to accept it. We are mirroring 2 80GB SSDs for the MDT, but the <br>
number of<br>
inodes is getting set to 7 million, which is not enough for a 100TB <br>
filesystem.<br>
<br>
Thanks in advance.<br>
<br>
-Anjana Kar<br>
Pittsburgh Supercomputing Center<br>
kar@psc.edu<br>
_______________________________________________<br>
Lustre-discuss mailing list<br>
Lustre-discuss@lists.lustre.org<br>
http://lists.lustre.org/mailman/listinfo/lustre-discuss<br>
</div>
</div>
</div>
</div>
</body>
</html>