[Lustre-discuss] NFS vs Lustre

Brian J. Murrell Brian.Murrell at Sun.COM
Mon Aug 31 13:34:58 PDT 2009


On Mon, 2009-08-31 at 21:56 +0200, Daniel Kobras wrote:
> Hi!

Hi,

> Lustre's
> standard config follows Posix and allows dirty client-side caches after
> close(). Performance improves as a result, of course, but in case something
> goes wrong on the net or the server, users potentially lose data just like on
> any local Posix filesystem.

I don't think this is true.  This is something that I am only
peripherally knowledgeable about and I am sure somebody like Andreas or
Johann can correct me if/where I go wrong...

You are right that there is an opportunity for a client to write to an
OST and get it's write(2) call returned before data goes to physical
disk.  But Lustre clients know that, and therefore they keep the state
needed to replay that write(2) to the server until the server sends back
a commit callback.  The commit callback is what tells the client that
the data actually went to physical media and that it can now purge any
state required to replay that transaction.

Until that write callback is received, the client holds on to whatever
state it would need to do that write(2) all over again, for exactly the
case you cite which is the server goes down before the data goes to
physical media.

It is this data that the client is caching until the commit callback is
received that is used by the recovery mechanisms that start when a
target comes back on-line.

Hope that clarifies things, and further, I hope my understanding is
correct as is my explanation.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20090831/82d86932/attachment.pgp>


More information about the lustre-discuss mailing list