[Lustre-discuss] Client directory entry caching

Oleg Drokin oleg.drokin at oracle.com
Tue Aug 3 20:14:31 PDT 2010


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.

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


More information about the lustre-discuss mailing list