On Fri 27-04-07 12:09:42, Andreas Dilger wrote: > On Apr 26, 2007 21:29 +0200, Jan Kara wrote: > > I've been lately playing with remapping ext2/ext3 blocks (especially how > > much it can give us in terms of speed of things like KDE start). For that > > I've written two simple tools (you can get them from > > ftp.suse.com/pub/people/jack/ext3remapper.tar.gz): > > e2block2file to transform (preparsed) output from blktrace into a list > > of accessed files and offsets accessed > > e2remapblocks to use output from e2block2file and remap blocks into big > > chunks in the order in which they were accessed. > > Does it map the whole file contiguously, or does it interleave blocks of the > file in the order they are accessed? I would hope that it maps the whole > file contiguously, and let readahead work properly to fetch the whole file. > Also, keeping the file contiguous avoids fragmentation later if that file is > updated, deleted, etc, and conflicts with allocator/defrag/etc. No, it does interleave blocks of different files. Reading the whole file is exactly what you often don't want. During startup KDE (which was my benchmark) accesses basically two things: shared libraries and config files / icons. Config files and icons usually fit into a single block so just mapping them in the right order close together is fine. On the other hand, shared libraries are large and you usually need just a few blocks scattered all over them. So here we just remap those few blocks we need... I see the downsides of this approach. If the file is rewritten, you loose the tight packing, but this is not going to happen often. I'm more seriously concerned about the possibility, that this optimizatiom of startup time may hurt running performace or more probably performance of other apps... > > (see README in the tools archive for more details) > > > > So far the tools (especially e2remapblocks ;) work on unmounted > > filesystem. The ultimate goal is to be able to do similar things for > > mounted filesystems but I wanted to see whether block remapping is worth it > > and what kernel interfaces would be useful for achieving the goal. > > I'd prefer that such functionality be integrated with Takashi's online > defrag tool, since it needs virtually the same functionality. For that Yes, definitely these two have quite similar needs and I'd like to have just one tool in the end. > matter, this is also very similar to the block-mapped -> extents tool > from Aneesh. It doesn't make sense to have so many separate tools for > users, especially if they start interfering with each other (i.e. defrag > undoes the remapping done by your tool). Agreed. Honza -- Jan Kara <jack@xxxxxxx> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
