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 ([EMAIL PROTECTED]) Linux Technology Center IBM Software Lab, India - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
