From: Goldwyn Rodrigues <grodrgs2@illinois.edu>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [RFC] ocfs2/dlm: support range lock
Date: Thu, 29 Jan 2015 05:04:06 -0600 [thread overview]
Message-ID: <54CA13A6.8070702@illinois.edu> (raw)
In-Reply-To: <54C9D63C.9010401@huawei.com>
Yangwenfang,
On 01/29/2015 12:42 AM, yangwenfang wrote:
> On 2015/1/27 15:08, Srinivas Eeda wrote:
>> Hi Yangwenfang,
>>
>> thank you very much for initiating this RFC :). This feature is long due for OCFS2 and we are also interested in implementing this feature. Wengang(cc'ed) has been looking into analysing and giving an attempt to implement it. We haven't looked at splitting and merging the range locking yet, but looked at having lock fairness and range locking. Wengang has done some of the dlm changes to see how it can be done but other changes are still work in progress. We will email more details in coming few days.
>>
>> Since you are also looking into it, it would be great if we can collaborate work on this feature. Can you please share more info on the demo code you mentioned ? Like what it does and how much work has been done on this ?
>>
> Hi,
> About 6k lines of code was modified including dlmglue and dlm in our demo.
>
> code modification:
> 1.read/write IO: get the range(start, end) and call ocfs2_range_lock.
> 2.dlmglue: modify key data struct: each inode has one ocfs2_lock_res including many range locks which have different range.
> determine the existance of conflicts betwen multiple threads within the node.
> manage the cache of range lock to support unlock-delay.
> 3.dlm: determine the existance of conflicts betwen multiple nodes.
> add splitting and merging the range locking.
> 4.lib: interval tree.
>> One of the thing we considered was making the rw lock itself support range locking, which is a different approach from what you mentioned. Is there any reason why rw lock cannot be used and we needa new ip_range_lock_lockres ?
>>
> RW lock can be used, but it is complicated to add the feature to rw_lock because RW lock is also applicated in read/write/truncate.
> Byte range lock is only beneficial for update write, so I just modify write IO to finish the demo to get performance results as soon as possible.
> I think ocfs2_rw_lock(pr) + ocfs2_range_lock(start, end, ex) are equivalent to ocfs2_rw_lock(ex)?am I rigth?
Okay, let me ask this question in another way: What is the purpose of
ocfs2_rw_lock(pr) in *this* scenario, where you are using
ocfs2_range_lock in conjunction with ocfs2_rw_lock. What is
ocfs2_rw_lock guarding?
--
Goldwyn
next prev parent reply other threads:[~2015-01-29 11:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-26 12:28 [Ocfs2-devel] [RFC] ocfs2/dlm: support range lock yangwenfang
2015-01-27 7:08 ` Srinivas Eeda
2015-01-29 6:42 ` yangwenfang
2015-01-29 11:04 ` Goldwyn Rodrigues [this message]
2015-01-30 2:59 ` Xue jiufei
2015-01-30 12:37 ` Goldwyn Rodrigues
2015-01-31 4:15 ` yangwenfang
2015-01-29 11:07 ` Goldwyn Rodrigues
2015-01-29 0:05 ` Goldwyn Rodrigues
2015-01-29 3:21 ` Wengang Wang
2015-01-29 7:47 ` yangwenfang
2015-01-29 8:06 ` Wengang Wang
2015-01-30 3:54 ` yangwenfang
2015-01-30 6:02 ` Wengang Wang
2015-01-30 7:46 ` yangwenfang
-- strict thread matches above, loose matches on Subject: below --
2015-01-28 8:43 David Weber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54CA13A6.8070702@illinois.edu \
--to=grodrgs2@illinois.edu \
--cc=ocfs2-devel@oss.oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.