From: Allison Henderson <achender@linux.vnet.ibm.com>
To: Tao Ma <tm@tao.ma>
Cc: Yongqiang Yang <xiaoqiangnk@gmail.com>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
"Ted Ts'o" <tytso@mit.edu>, Andreas Dilger <adilger@dilger.ca>
Subject: Re: Delayed Extent Tree and Extent Lock Tree
Date: Wed, 01 Feb 2012 15:04:25 -0700 [thread overview]
Message-ID: <4F29B6E9.3060008@linux.vnet.ibm.com> (raw)
In-Reply-To: <4F28E936.20303@tao.ma>
On 02/01/2012 12:26 AM, Tao Ma wrote:
> Hi Allison,
> On 02/01/2012 06:33 AM, Allison Henderson wrote:
>> Hi Yongqiang,
>>
>> I've have been working on an extent lock implementation that uses an
>> rbtree to keep track of locked extents, and I think I will probably end
>> up with a something similar to the tree that you've already set up for
>> delayed extents. So I wanted to send a note out to see what folks would
>> think about the idea of merging the two solutions.
>>
>> If we did this, the tree would get a little more complex in that it
>> would have to keep track of more than just delayed extents. It would
>> have to keep track of all extents and the processes that are waiting on
>> them. So I guess it would kind of turn into an extent status tree. I
>> also realize that some folks wanted to see range locks go into /lib as
>> general purpose code so that other filesystems or kernel code could use
>> it too, but the advantage to this approach would be one less tree for
>> ext4 to keep track of. Any thoughts?
> We (Taobao) are very interested in this stuff and it should benefit
> several of our workload(It is on our todo list for a long time). I guess
> Yongqiang's solution is a little bit limited to the only delayed extent
> case, and your new solution at least has 2 more benefits:
> 1. improve the direct i/o read/write
> 2. speed up the extent search since now we only cache one in
> ei_cached_extent.
>
> So please go ahead with your new solution. btw, do you have any timeline
> for it? We are glad to provide any help if needed.
>
> Thanks
> Tao
>
Thx all for the feed back, it sounds like there will be a lot of
benefits to extending Yongqiang's delayed extent tree, so I will work on
a solution based on that patch set. Unfortunately though, I cannot give
a time frame for this work item at the moment. There are currently some
other business needs that may take priority over this one, and until
those have been decided, I cannot make any promises at this point in
time. But I will work as quickly as I can with it since it is currently
on my plate, and I will keep folks updated. At the moment, feed back
and guidance is most helpful to me. Also, since the delayed extent
solution is now a dependency for my solution, anything to help get that
reviewed and merged would help me too. Yongqiang, does the set still
need review? I think I recall Ted saying it was still on his list of
things to look at. Im sure I will give it some good exercise here too.
Thx all for your help! :)
Allison Henderson
next prev parent reply other threads:[~2012-02-01 22:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-31 22:33 Delayed Extent Tree and Extent Lock Tree Allison Henderson
2012-02-01 7:26 ` Tao Ma
2012-02-01 17:47 ` Andreas Dilger
2012-02-01 22:04 ` Allison Henderson [this message]
2012-02-03 9:00 ` Yongqiang Yang
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=4F29B6E9.3060008@linux.vnet.ibm.com \
--to=achender@linux.vnet.ibm.com \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=tm@tao.ma \
--cc=tytso@mit.edu \
--cc=xiaoqiangnk@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).