On Tue, Jun 28, 2011 at 6:21 AM, Kazuya Mio <k-mio@xxxxxxxxxxxxx> wrote: > 2011/06/26 11:16, Greg Freemyer wrote: >> >> I'm talking about sparse files. >> >> Where you might have: >> >> block_group1 - hole - block_group2 - hole - block_group3. >> >> Block_group2 has a head and a tail extent. In my mind, from a >> performance perspective, they are symmetric. Meaning that having a >> small extent at the beginning is no better and no worse than having a >> small extent at the end. > > Thanks for your kind description. Your point is right. I'll think a little > more > about the fragmentation score. > > Regards, > Kazuya Mio Kazuya, 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. 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. Greg -- 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
