I don't think you've adequately gone over the methodology ericyifeng. If a request in that chart is being served by the cache because the read-ahead algorithm caught it, it is the disk cache not the OS cache that acted. The disk cache acts independently of the OS. Your objections do not relate to the SR methodology. The OS cache is not involved in caching IPeak trace replays. So every cache hit Eugene notes is going to occur under this workload on any OS. IPeak isolates the disk subsystem, which is why it is such a valuable tool.
You need to make sure you understand a methodology before you declare it flawed.
I was not saying the methodology is flawed. I was just questioning the analysis which calculates the potential improvement on 8GB+ (or 16M+ sectors) seeks only and draws the conclusion that the improvement would be insignificant.
OK, let's talk about the hardware disk cache. Are you saying that seeks between, say, 1K and 16M sectors can be absorbed by the disk cache? I don't know the disk cache internals. However, it's hard for me to imagine that the disk cache would do such large read-aheads (1K - 16M sectors or 0.5MB - 8GB), especially when the disk is actually busy.
BTW: is the hardware disk cache on or off in the IPEAK SPT tests? If it's on, then why are we seeing considerable time spent on seeks between 512 and 16M sectors if they should be cached? If it's indeed off, well, that's good to know and can we also see the times with the cache on?
Did you take into account rotational latency? A hard disk drive isn't RAM. Just because there's latency doesn't mean there's a seek. According to the data, you did not. I'm sorry if this sounds harsh, but judging from the blatant flaws in your critques, you honestly need to sit back and learn a little more before you criticize the work of someone who has been doing this for years.
And before you redo your math to include rotational latency, and you tell me that I'm wrong. Make sure you do it with worse case latency, not average latency.
I hope this clarifies the nature of the issues that you raised. They are nothing more than spectres that research would have dismissed.
The graphs clearly state "Read Seek Profile" so I naturally ignored rotational latency. So what are the graphs really meant to show? Seek latency? Rotational latency? Or both?
BTW: I'm an infrequent visitor to the SR website so I'm not familar with the test methodology used here. I stumbled upon this discussion from the main page link and I'm just saying what I feel might be wrong. After all I guess the forum is meant to stimulate discussion rather than follow what the authoritative say. I apologize if my words are offensive.