On Mon 30-04-07 08:09:30, Theodore Tso wrote: > On Fri, Apr 27, 2007 at 12:09:42PM -0600, Andreas Dilger wrote: > > I'd prefer that such functionality be integrated with Takashi's online > > defrag tool, since it needs virtually the same functionality. For that > > 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). > > Yep, in fact, I'm really glad that Jan is working on the remapping > tool because if the on-line defrag kernel interfaces don't have the > right support for it, then that means we need to fix the on-line > defrag patches. :-) ;-) Exactly that was the reason why I wrote the userspace program - so that I have something in hands when we start discussing how the kernel interface will look like. > While we're at it, someone want to start thinking about on-line > shrinking of ext4 filesystems? Again, the same block remapping > interfaces for defrag and file access optimizations should also be > useful for shrinking filesystems (even if some of the files that need > to be relocated are being actively used). If not, that probably means > we got the interface wrong. Yes, that's a good idea. Currently it seems to me that block+inode relocation (we also need for defrag) would be enough to support filesystem shrinking. Actually, in some ancient times (like 6-7 years ago) I had written ext2 online filesystem shrinking. Currently, the patch is probably unusably obsolete but I can still dig it out and look what functions did I need at that time. Honza -- Jan Kara <jack@xxxxxxx> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
