Re: [Ext2-devel] Reviewing ext3 improvement patches (delalloc, mballoc, extents)

[Badari Pulavarty <pbadari@us.ibm.com>]

On Thu, 2005-03-03 at 00:33, Suparna Bhattacharya wrote:
> Since the performance improvements seen so far are quite encouraging, 
> and momentum is picking up so well, I started looking through the
> patches from Alex ... just a quick code walkthrough to get a hang
> of it and think about what kind of simplifications might be possible
> and what it might take for inclusion.
> 
> I haven't had a chance to go too deep line by line yet,
> but thought I'd initiate some discussion with some first impressions
> and summary of what directions I hear several people converging
> towards to validate if I'm on the right track here.
> 
> diffstat of the 3 patches : 22 files changed, 5920 insertions(+), 
> 47 deletions. The largest is in the extents patch (2743), mballoc 
> is 1968, and delalloc is 1209. To use delalloc, which gives us
> all the performance benefits, right now we need all the 3 patches
> to be used in conjunction. Supporting extent map btrees as well 
> as traditional indexing and associated options for compatibility etc
> is perhaps the more invasive of changes. Given that keeping ext3 
> stable and maintainable is a key concern (that is after all a major 
> reason why a lot of users rely on ext3), a somewhat incremental 
> approach is desirable. 
> 
> So, I'll start from the direction that has been suggested by
> some -- (1) delayed allocation without changing the
> on-disk format. And then later (2) go on to breaking format with 
> all changes for scalability to larger files with full extents 
> support (haven't thought enough about this yet - maybe in a
> separate mail)
> 

Just doing delayed allocation without multiblock allocation
(with the current layout) is not really a useful thing, IMHO.
We will benifit few cases, but in general - we moved the
block allocation overhead from prepare write to writepages/writepage
time. There is a little benifit of not doing journaling twice etc..
but I don't think it would be enough to justify the effort. 
Isn't it ?

So, may be we should look at adding multiblock allocation +
delayed allocation to current ext3 layout. Then we can evaluate
the benifits of having "extents" etc and then break the layout ?

One more thing, we need to keep in mind is - we need to make sure
that "ordered" mode also improved - since all our testcode 
focuses on "writeback" mode and the default mode is "ordered" :(


Thanks,
Badari