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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
