From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: Reviewing ext3 improvement patches (delalloc, mballoc, extents) Date: Thu, 3 Mar 2005 02:40:21 -0700 Message-ID: <20050303094021.GY27352@schnapps.adilger.int> References: <20050303083349.GA4896@in.ibm.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+Q+8OJFh4jU0hFnf" Cc: ext2-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, Alex Tomas To: Suparna Bhattacharya Content-Disposition: inline In-Reply-To: <20050303083349.GA4896@in.ibm.com> Sender: ext2-devel-admin@lists.sourceforge.net Errors-To: ext2-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: List-Id: linux-fsdevel.vger.kernel.org --+Q+8OJFh4jU0hFnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mar 03, 2005 14:03 +0530, Suparna Bhattacharya wrote: > diffstat of the 3 patches : 22 files changed, 5920 insertions(+),=20 > 47 deletions. The largest is in the extents patch (2743), mballoc=20 > 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=20 > as traditional indexing and associated options for compatibility etc > is perhaps the more invasive of changes. Given that keeping ext3=20 > stable and maintainable is a key concern (that is after all a major=20 > reason why a lot of users rely on ext3), a somewhat incremental=20 > approach is desirable.=20 >=20 > 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=20 > all changes for scalability to larger files with full extents=20 > 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: >=20 > - 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/ --+Q+8OJFh4jU0hFnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFCJtuFpIg59Q01vtYRAoZgAKCNsodK1yqlVbS7bU2Jy9ZDNEA3pACfRQvV aIy/9kGhubIeN2ieGiMf+QQ= =xFPy -----END PGP SIGNATURE----- --+Q+8OJFh4jU0hFnf-- ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click