<div>I've put together a small patch to modify ll_dir_readpage and mdc_readpage to read extra pages (if available) with each RPC.  It is posted under the bug (<a href="https://bugzilla.lustre.org/show_bug.cgi?id=17833">https://bugzilla.lustre.org/show_bug.cgi?id=17833</a>).  I see you we're the original assignee when you were at Sun/Oracle.</div>

<div> </div>
<div>Jeremy<br><br></div>
<div class="gmail_quote">2010/9/29 Fan Yong <span dir="ltr"><<a href="mailto:yong.fan@whamcloud.com">yong.fan@whamcloud.com</a>></span><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div bgcolor="#ffffff" text="#000000">
<div>
<div></div>
<div class="h5">On 9/30/10 3:01 AM, Jeremy Filizetti wrote: 
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<div bgcolor="#ffffff" text="#000000"><br>On the other hand, Large readdir RPCs is basic of another metadata read performance improvement features - "readdir+", which is quite useful for "ls -l" operation (for large directory), and reduce lookup/getattr RPC as much as possible. In such feature, MDS will pack more dir-item's attribute (not only name/ino as does currently by readdir, but also mode/owner, and etc) information back to client-side in "readdir+" RPC. That means the dir-item count in one "readdir+" page is less than in the traditional readdir page, then more pages to be sent back to client. If without "Large readdir RPCs", the advantage of "readdir+" will be discounted.<br>
</div></blockquote>
<div> </div>
<div>I'd be interested in working this as well but probably as a separate effort since SOM isn't in 1.8 and that's my main focus.  In our testing, SOM had significant benefits over the WAN and I'd expect even better from readdir+.  I have tried Oleg's patch for asynchronous ll_glimpse_size but oddly I've seen someone erradic performance where at times it was worse then statahead and synchronous ll_glimpse_size.</div>

<div> </div>
<div>Jeremy</div>
<div> </div></div></blockquote></div></div>Yes, SOM is another important feature for metadata reading performance improvement by bypassing the glimpse RPC between client and OSS. Engineers from Lustre Group worked for that for some time, hope can be released soon.<br>
<br>As for the asynchronous ll_glimpse_size maybe cause bad performance occasionally, one possible reason is that: glimpse RPC maybe not obtain extent lock(s) if some others in using such lock(s), so the file size information obtained by asynchronous glimpse is invalid when it is really used later, means the caller ("stat") has to send synchronous glimpse again. Anyway, I did not study such patch, so it is just a guess.<br>
<br><br>Cheers,<br>Nasf<br></div><br>_______________________________________________<br>Lustre-devel mailing list<br><a href="mailto:Lustre-devel@lists.lustre.org">Lustre-devel@lists.lustre.org</a><br><a href="http://lists.lustre.org/mailman/listinfo/lustre-devel" target="_blank">http://lists.lustre.org/mailman/listinfo/lustre-devel</a><br>
<br></blockquote></div><br>