Re: Reviewing ext3 improvement patches (delalloc, mballoc, extents)

[Andreas Dilger <adilger@clusterfs.com>]

[-- Attachment #1: Type: text/plain, Size: 2380 bytes --]

On Mar 03, 2005  14:03 +0530, Suparna Bhattacharya wrote:
> 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)

Well, for a starter, the extents format changes are not forced on
users, only if they mount with "-o extents" and write files will
it mark the superblock incompatible and start allocating files
this way.  I believe (though I have never tested) that even if
extents are enabled, writes to a block-mapped file will continue
to work and that file will not be converted to an extent file.

> A few random things that come to mind for (1), going through the code:
> 
> - There might be possibilities for code reduction, by extending
>   generic routines as far as possible, e.g. ext3_wb_writepages
>   has a lot in common with generic writepages. That would
>   also make it easier to maintain.

I'm sure some support for this could be gotten from e.g. XFS as well,
since their filesystem (on Irix at least) was all about delayed alloc
(not sure what it does under Linux), and I believe ReiserFS/Reiser4
also desire the ability to have delayed allocation from the VFS (i.e.
some sort of light-weight "reserve space" call for each page dirtied
and then getting the actual file + offsets en masse later (if the
VFS/VM doesn't discard the whole thing).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/             http://members.shaw.ca/golinux/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]