[Lustre-discuss] Client directory entry caching

Jeremy Filizetti jeremy.filizetti at gmail.com
Tue Aug 3 21:22:05 PDT 2010


On Tue, Aug 3, 2010 at 11:14 PM, Oleg Drokin <oleg.drokin at oracle.com> wrote:

> Hello!
>
> On Aug 3, 2010, at 10:59 PM, Jeremy Filizetti wrote:
>
> > 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.
>
>

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).

Jeremy

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.
> 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
> 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
> on a client already and server support is mostly trivial.
> 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
> fetch read locks only, so would not help in case of writes).
> See bug 11715 for discussions and hopefully for patches that would
> eventually come.
>
> 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.
>
> Bye,
>     Oleg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20100804/2e7d3d57/attachment.htm>


More information about the lustre-discuss mailing list