linux-ext4 - Re: Delayed Extent Tree and Extent Lock Tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 01 Feb 2012 15:04:25 -0700
From:	Allison Henderson <achender@...ux.vnet.ibm.com>
To:	Tao Ma <tm@....ma>
CC:	Yongqiang Yang <xiaoqiangnk@...il.com>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	"Ted Ts'o" <tytso@....edu>, Andreas Dilger <adilger@...ger.ca>
Subject: Re: Delayed Extent Tree and Extent Lock Tree

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

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html