Linux ext4 development ()

Zheng Liu | 21 Jun 2012 11:46

[RFC] ext4: add an io-tree to track block allocation

Hi all,

This year at ext4 workshop a new idea that calls io-tree is proposed to
solve some problmes in ext4 [1].  I summarize the problems that are
needed to solve by io-tree in here:
1. reserve quota calculation in bigalloc
2. simplify puch hole implementation
3. simplify fiemap implementation
4. SEEK_DATA/HOLE implementation

Meanwhile with io-tree, some codes can be improved as following:
1. accelerate get_block functions
2. simplify uninitialized extent conversion
3. fine granularity locking (extent lock)

I make a plan to implement io-tree that can be divided into three-steps.
Now I describe it in detailed.

* Step 1
The following problems will be solved in this step:
1. reserve quota calculation in bigalloc
2. simplify puch hole implementation
3. simplify fiemap implementation
4. SEEK_DATA/HOLE implementation

Currently a patch set has been submitted to the mailing list by
Yongqiang and Allison, which called status extent tree, and it has
simplified fiemap implementation.  But it only works when delay
allocation is enabled.  I will pick up this work.  Now I have rebased
this patch set to 3.5-rc3, and renamed it to extent status tree as

(Continue reading)

headers

Yongqiang Yang | 21 Jun 2012 13:04

Re: [RFC] ext4: add an io-tree to track block allocation

On Thu, Jun 21, 2012 at 5:46 PM, Zheng Liu <gnehzuil.liu <at> gmail.com> wrote:
> Hi all,
>
> This year at ext4 workshop a new idea that calls io-tree is proposed to
> solve some problmes in ext4 [1].  I summarize the problems that are
> needed to solve by io-tree in here:
> 1. reserve quota calculation in bigalloc
> 2. simplify puch hole implementation
> 3. simplify fiemap implementation
> 4. SEEK_DATA/HOLE implementation
Actually, we can accelerate
 ext4_da_write_cache_pages by looking up extent status tree rather
than page cache.  This is one of aims of the original patch sets.

>
> Meanwhile with io-tree, some codes can be improved as following:
> 1. accelerate get_block functions
> 2. simplify uninitialized extent conversion
> 3. fine granularity locking (extent lock)
>
> I make a plan to implement io-tree that can be divided into three-steps.
> Now I describe it in detailed.
>
> * Step 1
> The following problems will be solved in this step:
> 1. reserve quota calculation in bigalloc
> 2. simplify puch hole implementation
> 3. simplify fiemap implementation
> 4. SEEK_DATA/HOLE implementation
>

(Continue reading)

headers

Zheng Liu | 21 Jun 2012 13:48

Re: [RFC] ext4: add an io-tree to track block allocation

On Thu, Jun 21, 2012 at 07:04:31PM +0800, Yongqiang Yang wrote:
> On Thu, Jun 21, 2012 at 5:46 PM, Zheng Liu <gnehzuil.liu <at> gmail.com> wrote:
> > Hi all,
> >
> > This year at ext4 workshop a new idea that calls io-tree is proposed to
> > solve some problmes in ext4 [1].  I summarize the problems that are
> > needed to solve by io-tree in here:
> > 1. reserve quota calculation in bigalloc
> > 2. simplify puch hole implementation
> > 3. simplify fiemap implementation
> > 4. SEEK_DATA/HOLE implementation
> Actually, we can accelerate
>  ext4_da_write_cache_pages by looking up extent status tree rather
> than page cache.  This is one of aims of the original patch sets.

Thanks for the feedback.  I will add it in my TODO list.

> 
> >
> > Meanwhile with io-tree, some codes can be improved as following:
> > 1. accelerate get_block functions
> > 2. simplify uninitialized extent conversion
> > 3. fine granularity locking (extent lock)
> >
> > I make a plan to implement io-tree that can be divided into three-steps.
> > Now I describe it in detailed.
> >
> > * Step 1
> > The following problems will be solved in this step:
> > 1. reserve quota calculation in bigalloc

(Continue reading)