[Lustre-devel] Commit on share

Peter Braam Peter.Braam at Sun.COM
Tue May 27 03:44:18 PDT 2008


This HLD is definitely not ready at all.  It is very short, lacks
interaction diagrams and the arguments made are not sufficiently detailed.

* the second sentence is not right.  Commit should happen before
un-committed data coming from a client is shared with a 2nd client.
* Is COS dependent on VBR ­ no it is not, and can equally apply to normal
recovery 
* Section 3.2 is wrong: the recovery process will not fail with gaps in the
sequence when there is VBR.  It only fails if there are gaps in the
versions, and this is rare.
* 3.3 parallel creations in one directory are protected with different,
independent lock resources.  Isn¹t that sufficient to allow parallel
operations with COS?
* 3.6 provide a detailed explanation please
* GC thread is wrong mechanism this is what we have commit callbacks for
* Why not use the DLM, then we can simply keep the client waiting ­ the
mechanism already exists for repack; I am not convinced at all by the
reasoning that rep-ack is so different ­ no real facts are quoted
* It is left completely without explanation how the hash table (which I
think we don¹t need/want) is used

Regards,

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20080527/11a2ef8f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: commit-on-sharing-simple-tracking-hld.pdf
Type: application/octet-stream
Size: 63433 bytes
Desc: not available
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20080527/11a2ef8f/attachment.obj>


More information about the lustre-devel mailing list