<br><div class="gmail_quote">On Tue, Aug 3, 2010 at 11:14 PM, Oleg Drokin <span dir="ltr"><<a href="mailto:oleg.drokin@oracle.com">oleg.drokin@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello!<br>
<div><br>
On Aug 3, 2010, at 10:59 PM, Jeremy Filizetti wrote:<br>
<br>
> Another consideration for WAN performance when creating files is the stripe count.  When you start writing to a file the first RPC to each OSC requests the lock rather then requesting the lock from all OSCs when the first lock is requested.  This would require some code to change but it would be another nice optimization for WAN performance.  We do some work over a 200 ms RTT latency and to create a file striped across 8 OSTs with 1 MB stripes takes 1.6 seconds just to write the first 8 MBs sine the locks are synchronous operations.  For a single stripe it would only take ~200 ms.<br>
 
<br></div></blockquote><div><br>Our workload is primarily WORM (write once read many) so we never have shared write access.  I would be nice to have a client option to enable this capability that would remain off by default.  Extracting a tar can become painful when it has some small files but we need the extra stripes for concurrency that provide good performance for the larger files (which take more time anyways).<br>
<br>Jeremy<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
</div>Requesting locks on all stripes would be a disaster for shared-file type of workload where a single file is accessed by a lot of clients.<br>
If you know that your app is the only one doing accesses and you would agree to do some extra actions (sure this is limited), the glimpse handler<br>
could be modified in such a way that it would grant you a write lock if your file handle was opened for write, I think we have support for this<br>
on a client already and server support is mostly trivial.<br>
So with that change you would open/create a file for write and then do fstat that would fetch you your locks in parallel (currently this would<br>
fetch read locks only, so would not help in case of writes).<br>
See bug 11715 for discussions and hopefully for patches that would eventually come.<br>
<br>
This could be done in a nicer way of course, but would be a much bigger piece of work too which would mean it's much longer to wait too.<br>
<br>
Bye,<br>
<font color="#888888">    Oleg</font></blockquote></div><br>