From: Allison Henderson <achender@linux.vnet.ibm.com>
Subject: Re: Extent tree status asking
Date: Fri, 20 Apr 2012 17:12:44 -0700
Message-ID: <4F91FB7C.1050109@linux.vnet.ibm.com>
References: <20120416175534.GA5533@gmail.com> <4F8E5CEE.9050607@linux.vnet.ibm.com> <20120419093829.GA4547@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
To: linux-ext4 <linux-ext4@vger.kernel.org>
In-Reply-To: <20120419093829.GA4547@gmail.com>
Sender: linux-ext4-owner@vger.kernel.org

On 04/19/2012 02:38 AM, Zheng Liu wrote:
> On Tue, Apr 17, 2012 at 11:19:26PM -0700, Allison Henderson wrote:
>> On 04/16/2012 10:55 AM, Zheng Liu wrote:
>>> Hi Allison,
>>>
>>> Currently I am trying to reduce the lock contention of direct I/O in ext4
>>> because it is a bottleneck.  A trivial idea is that a new fucntion is
>>> defined to replace the generic_file_aio_write, which do some write
>>> operations with acquiring i_data_sem lock in inode.
>>>
>>> I know that you are trying to implement extent tree, and I have seen your patch
>>> set '[PATCH] Rename delayed extents to status extents'.  After extent tree is
>>> made, the implementation of direct I/O without i_mutex and range lock is
>>> straightforward and it is better than my trivial idea.  I think that
>>> maybe I can borrow you works.  So could you please share me your schedule
>>> and/or other information?
>>>
>>> Last month on ext4 workshop, we discuss the extent tree, range lock and I/O
>>> tree.  Obviously, I/O tree is used to store I/O operations, which can track
>>> delay allocation, do unwritten->written conversion and implement range lock.
>>> It is very useful for ext4 and I am interested in this proposal.  I know that
>>> you have begun to do some works.  So would you like to tell me the status of
>>> extent tree?  I don't know whether or not there has some things that I can be
>>> involved.  If you have some advices or there is something that I can help,
>>> please let me know.  Thank you and looking forward your reply.
>>>
>>> Regards,
>>> Zheng
>>
>> Hi Zheng,
>>
>> Well, I can share with you what I have done so far with Yongqiang's
>> delayed extent tree, but since I was moved to the ganesha project,
>> extent locks are no longer a business priority now.  I've done some
>> work on it on my own time, but I have not been able to keep up pace
>> with it.  If someone else has the hours to push it faster than I can
>> at this point, I would certainly be understanding of that.
>>
>> Basically though the plan was to modify Yongqiang's delayed extent
>> tree to track allocated extents as well as delayed extents.  And
>> then add the extent locks on top of that once that's working.  My
>> idea was to add a type member to the extents so that we have have
>> "delayed" "allocated" and "hole" extents.  I've renamed the delayed
>> extent scheme to "status extents" because it seemed more
>> appropriate.  That part I can send out, but I was still in the
>> middle of coding and debugging allocated extents and extent locks.
>> Because the tree was originally written to merge things as much as
>> possible, there is some rewrite that is needed.  I was working on
>> making the add and remove routines more like "type replace" routines
>> sense once the extent is locked, we can really only change the type,
>> and we cannot merge dissimilar types or extents locked by other
>> processes. I hope that makes sense, please let me know if you need
>> more clarification.  I will send out the status extent set, sense
>> that part is stable.
>
> Thank you for sharing with me.  I am willing to take this work because
> my employee provides me a full time to finish this work.  I see that you
> have sent the patch set to the mailing list.  I will pick it and go on
> working.  Thanks again. :)
>
> Regards,
> Zheng
>

Alrighty then, thx Zheng for continuing this work item.  Let me know if 
you have any questions or need any help. :)

Allison Henderson