From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suparna Bhattacharya Subject: Re: [Ext2-devel] Reviewing ext3 improvement patches (delalloc, mballoc, extents) Date: Fri, 4 Mar 2005 08:56:36 +0530 Message-ID: <20050304032636.GA3777@in.ibm.com> References: <20050303083349.GA4896@in.ibm.com> <1109898734.4961.11.camel@dyn318077bld.beaverton.ibm.com> <1109900773.4637.9.camel@dyn318043bld.beaverton.ibm.com> Reply-To: suparna@in.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Badari Pulavarty , ext2-devel , linux-fsdevel@vger.kernel.org, Alex Tomas , akpm@osdl.org Received: from e31.co.us.ibm.com ([32.97.110.129]:40612 "EHLO e31.co.us.ibm.com") by vger.kernel.org with ESMTP id S262694AbVCDDQ7 (ORCPT ); Thu, 3 Mar 2005 22:16:59 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j243Gxua526140 for ; Thu, 3 Mar 2005 22:16:59 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j243GxPs140600 for ; Thu, 3 Mar 2005 20:16:59 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j243Gw0I011106 for ; Thu, 3 Mar 2005 20:16:58 -0700 To: Mingming Cao Content-Disposition: inline In-Reply-To: <1109900773.4637.9.camel@dyn318043bld.beaverton.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Mar 03, 2005 at 05:46:13PM -0800, Mingming Cao wrote: > 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. Yup this is exactly what I was thinking. It'll probably only be a step along the way ... but I am hoping that this will give us a direction to merge these pieces in incrementally, a little at a time, each piece being very well-understood and with demonstrated performance improvements at every step. For example, the next step after the following could be to plug parts of mballoc in to the above, etc ... Does that make sense ? Regards Suparna -- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Lab, India