From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mingming Cao Subject: Re: Lazy block allocation and block_prepare_write? Date: Tue, 19 Apr 2005 10:08:44 -0700 Message-ID: <1113930524.10380.64.camel@localhost.localdomain> References: <8e70aacf05041717546fdff3f@mail.gmail.com> <42647484.5040208@us.ibm.com> <16996.59873.671294.982899@gargle.gargle.HOWL> <1113921972.26913.417.camel@dyn318077bld.beaverton.ibm.com> Reply-To: cmm@us.ibm.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Badari Pulavarty , fsdevel Return-path: Received: from e31.co.us.ibm.com ([32.97.110.129]:49541 "EHLO e31.co.us.ibm.com") by vger.kernel.org with ESMTP id S261179AbVDSRIr (ORCPT ); Tue, 19 Apr 2005 13:08:47 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3JH8kua436150 for ; Tue, 19 Apr 2005 13:08:46 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3JH8kMp258972 for ; Tue, 19 Apr 2005 11:08:46 -0600 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 j3JH8jlV004907 for ; Tue, 19 Apr 2005 11:08:46 -0600 To: Nikita Danilov In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 2005-04-19 at 19:55 +0400, Nikita Danilov wrote: > Badari Pulavarty writes: > > > On Tue, 2005-04-19 at 04:22, Nikita Danilov wrote: > >> Badari Pulavarty writes: > >> > >> [...] > >> > >> > > >> > Yes. Its possible to do what you want to. I am currently working on > >> > adding "delayed allocation" support to ext3. As part of that, We > >> > >> As you most likely already know, Alex Thomas already implemented delayed > >> block allocation for ext3. > > > > Yep. I reviewed Alex Thomas patches for delayed allocation. He handled > > all the cases in his code and did NOT use any mpage* routines to do > > the work. I was hoping to change the mpage infrastructure to handle > > these, so that every filesystem doesn't have to do their thing. > > > > Just keep in mind that filesystem != ext3. :-) Generic support makes > sense only when it is usable by multiple file systems. This is not > always possible, e.g., there is no "generic block allocator" for > precisely the same reason: disk space allocation policies are tightly > intertwined with the rest of file system internals. > This generic support should be useful for ext2 and xfs. From delayed allocation point of view, it should not aware any filesystem specific block allocation policies, and it should not care.:) It just simply gathering all pages that need to map block on disk, and asking the filesystem get_blocks() call back function, which will take care of the filesystem-specific multiple blocks mapping for it. Current get_blocks() function for ext3 is just simply loop calling ext3_get_block(). I am trying to add a real ext3_get_blocks() to reduce the cpu cost, reduce the number of metadata updates and increase the possibility to get contiguous blocks on disk.