2011/06/21 22:56, Ted Ts'o wrote:
I'm really nervous about having filefrag print a "fragmentation score". The problem is that the problem is invariably far more complex than can be boiled into a single number, and so users look at it and start worrying when they shouldn't.
It's possible that could happen. I suppose filefrag should output "fragmented" or "not fragmented" to understand when they shouldn't do e4defag. But it would be difficult to implement this idea because the threshold for the determination of which file is fragmented is different of each filesystem. As it stands now, I think filefrag shouldn't output fragmentation score. However, I think I add get_fragment_score() to libe2p because e4defrag will still use it.
And the statement, "so that e4defrag can compare two files' fragmentation to prevent the worse fragmentation" begs the question of what is "worse". The real issue here is that it's a multidimensional problem.
We need to define "what is worse" for e4defrag. If fragments per megabyte of the file is bigger than the threshold, e4defrag will call EXT4_IOC_MOVE_EXT ioctl. The threshold may be customizable by an option.
"fragments per megabyte" is definitely better, especially if you disregard the tail. It's worth consider how it works for files smaller than a megabyte. Do you round the file size up to the nearest megabyte? Is it an integer score, or does it need to be floating point? An integer score where the size is rounded up to the nearest megabyte sounds like a best plan, but I'm sure we could still find some interesting non-linearities that lead to surprising results.
An integer score sounds good to me. 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