On Mon, 12 August 2013 10:20:14 +0800, zwu.kernel@xxxxxxxxx wrote: > > The patchset is trying to introduce hot tracking function in > VFS layer, which will keep track of real disk I/O in memory. > By it, you will easily know more details about disk I/O, and > then detect where disk I/O hot spots are. Also, specific FS > can take use of it to do accurate defragment, and hot relocation > support, etc. I find this description extremely uninteresting. Sure, you can track hot now. Grammatically, I am missing a noun. Are you tracking hot pages, hot files or hot potatoes? More importantly, once you have identified the hot stuff, why should I care? What problem does it solve? The documentation patch at the end has a "motivation" paragraph, but the introduction email does not. As a result, every time you sent these patches, I quickly glanced at them, decided not to care and moved on. And finally, now that I have hunted down the motivation and know it is about caching stuff on ssd, I question your basic approach. Why do you want to touch the vfs at all and not do it as a block device driver? The big advantage of a block driver is that noone cares. People without ssd shouldn't care, as caching doesn't help them. People without spinning rust shouldn't care as caching doesn't help them either. And people with a mixture of both shouldn't care in a few years time, once they have fully transitioned to ssd. If you solve the problem in the vfs, I am forced to care. I cannot just select CONFIG_CACHING_BLOCK_DEVICE=n and be done with it. If you want me to carry such a cost for you, you better demonstrate some enticing advantages for me as well. There is no CONFIG_VFS=n, after all. Jörn -- Audacity augments courage; hesitation, fear. -- Publilius Syrus -- 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
