[Lustre-devel] Commit on share
Peter Braam
Peter.Braam at Sun.COM
Wed Jun 11 08:26:19 PDT 2008
On 6/11/08 8:21 AM, "Alexander Zarochentsev"
<Alexander.Zarochentsev at Sun.COM> wrote:
> Hello,
>
> On 27 May 2008 14:44:18 Peter Braam wrote:
>> This HLD is definitely not ready at all. It is very short, lacks
>> interaction diagrams and the arguments made are not sufficiently
>> detailed.
>
> is the following definition of dependent operation more clear?
>
> Operation B depends on operation A if:
>
> 1. A and B modify the same object
> 2. B modifies the object after A (LDLM serializes object access)
> 3. A isn't committed yet
> 4. A and B are issued by different clients
This shows a fundamental mistake, and one I was afraid of. If a second
client only reads uncommitted data there is already a dependency.
You need to read the database literature - this is standard stuff, here is a
link to a great book:
http://research.microsoft.com/~philbe/ccontrol/
Peter
>
>> * 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?
>
> The objects in the definition of dependent operation can be those parts
> of the directory identified by hash.
>
>> * 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;
>
> CoS is just an improved version of rep-ack, using persistent storage
> instead of client replay queue?
>
>> 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
>
> Thanks,
More information about the lustre-devel
mailing list