From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mingming Cao Subject: Re: [Ext2-devel] Reviewing ext3 improvement patches (delalloc, mballoc, extents) Date: Thu, 03 Mar 2005 17:46:13 -0800 Message-ID: <1109900773.4637.9.camel@dyn318043bld.beaverton.ibm.com> References: <20050303083349.GA4896@in.ibm.com> <1109898734.4961.11.camel@dyn318077bld.beaverton.ibm.com> Reply-To: cmm@us.ibm.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: suparna@in.ibm.com, ext2-devel , linux-fsdevel@vger.kernel.org, Alex Tomas Received: from e34.co.us.ibm.com ([32.97.110.132]:37581 "EHLO e34.co.us.ibm.com") by vger.kernel.org with ESMTP id S262791AbVCDBqR (ORCPT ); Thu, 3 Mar 2005 20:46:17 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j241kGKN364640 for ; Thu, 3 Mar 2005 20:46:16 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j241kG3V156320 for ; Thu, 3 Mar 2005 18:46:16 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j241kFrB015173 for ; Thu, 3 Mar 2005 18:46:15 -0700 To: Badari Pulavarty In-Reply-To: <1109898734.4961.11.camel@dyn318077bld.beaverton.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2005-03-03 at 17:12 -0800, Badari Pulavarty wrote: > 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 ? > Hi Badari I agree delayed allocation make much sense with multiblock allocation. But I still think itself worth the effort, even without multiple block allocation. If we have a seeky random write application, and if later the application try to fill those holes, we normally will end up pretty ugly file layout. With delayed allocation, we could have better chance to get contigous blocks on disk for that file. I happened found Ted has mentioned this before: http://marc.theaimsgroup.com/?l=ext2-devel&m=107239591117758&w=2 > 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 ? > Current reservation code could be improved to return back how big the free chunk inside the window, and we could use that to help make ext3_new_blocks()/ext3_get_blocks() happen.