On Tue, 2005-04-19 at 19:55 +0400, Nikita Danilov wrote: > Badari Pulavarty <[EMAIL PROTECTED]> writes: > > > On Tue, 2005-04-19 at 04:22, Nikita Danilov wrote: > >> Badari Pulavarty <[EMAIL PROTECTED]> 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. - 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
