<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Thanks Andreas for that link.</div><div>These look like great improvements certainly - but on an absolute scale:&nbsp;</div><div>is one minute for 100k 0-stripe files sufficient?</div><div>4.5 min for 100k 4-stripe files?&nbsp;</div><div>If not, is there a particular number that we think will be acceptable? &nbsp;Anyone have some GPFS numbers?</div><div><br></div><div><br></div><div><img id="a3066b78-60b9-43d0-8a33-1e0a424fab11" height="419" width="640" apple-width="yes" apple-height="yes" src="cid:0D0088CB-58E1-44AA-9239-76ECCF190559"></div><div><br></div><div>For the graph below, are these 0-stripe files? &nbsp;Liang's original pdirops report didn't show nearly these gains. &nbsp;Are there further changes is 2.3?</div><div><br></div><img id="88baecd5-b537-49e2-b465-e2241fbb8b9a" height="393" width="640" apple-width="yes" apple-height="yes" src="cid:B79A2196-97E7-418D-AC9E-EE8F0DC7F5F5"><div><br><div><div>On Apr 30, 2012, at 4:01 PM, Andreas Dilger wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 2012-04-30, at 2:48 PM, Nathan Rutman wrote:<br><blockquote type="cite">Right, these are different things. &nbsp;But both were intended to be metadata improvements.<br></blockquote><blockquote type="cite">The pdirops results have been posted, but for actual files (e.g. with OST objects) the create/unlink rates didn't show much improvement.<br></blockquote><br>I see this as a case of Amdahl's law - the MDS-only performance improvements from pdirops were reasonably good, but this is only part of the system being tested and improving performance of just the MDS will show diminishing returns if the OST performance isn't similarly improved.<br><br>I've long suspected that the MDS-OSS precreate operations could be improved through some in-depth analysis and profiling, and Ben @ Terascala showed some of this at LUG 2011 as well. &nbsp;Some of the MDS-side performance improvements (pdirops) will be available in the OSS stack once it moves over to using the OFD module (i.e. obdfilter on top of OSD), and some of the current SMP scaling work being done for LNet, libcfs, ptlrpc will also apply to the OSS.<br><br><blockquote type="cite">I have not seen any measurements of 'ls -la' for any delivered features (although that doesn't mean they don't exist).<br></blockquote><br>I posted some of these results in a recent presentation:<br><a href="http://storageconference.com/2012/Presentations/T01.Dilger.pdf">http://storageconference.com/2012/Presentations/T01.Dilger.pdf</a><br><br>The graphs on slide 13 were generated based on data from Fan Yong's testing, and I'd think this was delivered to OpenSFS, but I don't know if there was a separate presentation for these results elsewhere.<br><br><blockquote type="cite">The question now is, do we as OpenSFS members want to continue to prioritize single-server MDS performance improvements? <br></blockquote><br>I think it would be reasonable to have follow-on project for OSS SMP tuning (including OST precreate, among other things) once the current SMP work for LNET/ptlrpc is finished, along with a similar investment on the client side to ensure that it is not hitting SMP scaling bottlenecks as the number of cores on client nodes goes through the roof.<br><br>Cheers, Andreas<br><br><blockquote type="cite">On Apr 30, 2012, at 12:47 PM, Alex Tomas wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">hmm? pdirops is not supposed to improve directory listing, AFAIK.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">thanks, Alex<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On Mon, Apr 30, 2012 at 11:23 PM, Nathan Rutman &lt;Nathan_Rutman@xyratex.com&gt; wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">pdirops was delivered, but the improvement results were somewhat disappointing. &nbsp;I've seen no metrics for various directory listing improvements, although they may exist.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Should we set a target rate? E.g. "ls -al" for a dir with 100K single-stripe files?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On Apr 30, 2012, at 11:53 AM, John Carrier wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Nathan adds a good question: &nbsp;metadata performance was the focus of our last RFP. &nbsp;Are there any performance targets not covered by our current development contract?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">--jc<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Nathan Rutman added a comment to OpenSFS TWG Requirements 2012<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Nathan Rutman<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Metadata server performance<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Have we achieved the single-server MDS performance goals? Do we need to move some more solid requirements to 2012?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">discuss mailing list<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">discuss@lists.opensfs.org<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">http://lists.opensfs.org/listinfo.cgi/discuss-opensfs.org<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">twg mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">twg@lists.opensfs.org<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">http://lists.opensfs.org/listinfo.cgi/twg-opensfs.org<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">twg mailing list<br></blockquote><blockquote type="cite">twg@lists.opensfs.org<br></blockquote><blockquote type="cite">http://lists.opensfs.org/listinfo.cgi/twg-opensfs.org<br></blockquote><br><br>Cheers, Andreas<br>--<br>Andreas Dilger &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Whamcloud, Inc.<br>Principal Lustre Engineer &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;http://www.whamcloud.com/<br><br><br><br><br></div></blockquote></div><br></div></body></html>