2011/06/28 22:53, Greg Freemyer wrote:
While you're thinking about the issue: As I hope I've said before, for sparse file I think e4defrag should score and defrag one block_group at a time. Thus if a VM backing storage file has 100 block_groups (as I'm using the term), then it should score each of the 100 separately and if needed defrag them one at a time. I can see no benefit from treating a large sparse file as monolithic for the decision process.
If e4defrag does defrag one block_group at a time, this block_group may be allocated far away from the other block_groups. If so, seek time increases even if the number of extents is less than before. Of course, I'm aware of the advantage of your suggestion. I may also try to consider it to defrag only a part of a file in the future, but before that I think I should do the cleanup and bugfix.
fyi: Is there an agreed on term for what I'm calling a block_group. I believe e4defrag uses the term "extent group" in the comments, but sparse files exist in non-extent based filesystems, so it's not a very portable name.
e4defrag supports only an extent based filesystem, so I think it's no problem. And I associate "block_group" with the physical layout of the blocks on the disk. I guess we shouldn't use the same word with different meanings. Regards, Kazuya Mio -- 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
