I wonder how much of that is over-optimization for sequential reads. When I was working in filesystems (back in the spinning rust days), I saw some code whose j

I wonder how much of that is over-optimization for sequential reads. When I was working in filesystems (back in the spinning rust days), I saw some code whose job it was to prefetch the next several hunks of data when you accessed data - It was a scaling algorithm, so if the block you were accessing was already in memory it would read several more hunks, and the next time you accessed from that same sequence it'd read 2x more than that, up to a fairly high limit - It made sense in this context to, shortly after a file was opened, just read the entire file into memory if it seemed likely to be used in short order, because disk queue latency was often the major limiting factor. What this meant was an at least 2x and often 100x read amplification for truly random reads. There were some heuristics to disable that, too, and then drive controllers started doing this directly so some code to managed that interaction, issuing more early in the "pretty sure we want to read more" path but dialing back the scaling. I would not be surprised if this type of logic is implemented into modern SSD controllers directly. When you issue a random read, it actually reads several sectors ahead, just in case those are the next requests. If we disabled that - How much faster would the random reads path be? How much slower would the sequential be? I suspect (very heavily, given the availability of enterprise drives with precisely this kind of tuning available) that there's a lot of tradeoff to be made.