? 2015?01?29? 15:47, yangwenfang ??:> On 2015/1/29 8:05, Goldwyn Rodrigues wrote:
>> Hi Yangwenfang,
>>
>> I appreciate the effort in this regard.
>>
>> On 01/26/2015 06:28 AM, yangwenfang wrote:
>>> What:
>>> Byte range lock is applied to lock a region of a file to accelerate
>>> reading/writing concurrently.
>>> Each lock resource deploys an interval tree to manage the range,
which
>>> supports basic operations like add, delete, insert, find, split and
merge.
>>> The most important issue is to determine the existance of conflicts
>>> among the ranges. Conflict-free ranges of the same file can be
accessed
>>> concurrently. In the contrary, nodes must wait for the release of a
>>> conflicted lock before accessing the range of file.
>>>
>>> Byte range lock supports split and merge rules: for same level,
larger
>>> scope; different level, write > read(If a node keeps EX lock
with
>>> range(start,end), then it has PR range lock(start,end)).
>>> For example:
>>> (1) merge: N1 keeps range lock (0,9)PR and (5,19)PR, the lock is
merged into
>>> (0,19) PR;
>>> (2) merge: N1 keeps range lock (0,9)PR and (5,19)EX, the merged
lock should
>>> become(0,19) PR, (5,19)EX;
>>> (3) split: N1 keeps range lock (0,9)PR, N2 tries to lock(0,5) PR,
N1 should
>>> split the lock and keep (6,9)PR.
>> What is the purpose of doing this kind of merge/split? I assume this
will be required in case of multiple processes from the same node read/write to
the file. Would it not be simpler to not merge or split and keep separate
instances in lock resources? This way you would have to do relatively lesser
book keeping with respect to comparisons.
>>
> Hi,
> Realization of this kind of merge/split is for cache of range lock to
support unlock-delay.
> For example(the granularity is block size)
> 1.Node 1 writes to 0-9, it will keep the range lock(0,9,EX) if no other
node write the same range of file.
> 2.Node 1 writes to 10-19, then the range lock will be merged into
(0,19,EX). if not, the number of locks will be more and more.
> 3.Node 1 writes to 5-10, then no need to dlmlock from master.
> 3.Node 2 writes to 5-10, conflict with Node 1, so Node 1 will drop (5,10),
the range lock is splitted into (0,4) and (11,19).
What's the merge would be like in dlm module? Will it cause deadlock when
node1 extend 0-9 to 0-19 and node 2 extend 10-19 to 0-19?
thanks,
wengang
>> Are these numbers in your pseudocode byte ranges? If yes, how do you
propose multiple writes which lie within a block_size/cluster_size range?
>>
> No, the granularity of these numbers is block size or PAGE_SIZE. The
granularity is smaller, the conflict is more. Actually, we use 1M in our test.
>
> thanks,
> yangwenfang
>
>
>
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-devel