4 ms·

Let me clarify what I was saying: I was redundantly (for clarity) talking about cache on the SSD, trying to make it extra clear that I wasn't talking about any

Let me clarify what I was saying: I was redundantly (for clarity) talking about cache on the SSD, trying to make it extra clear that I wasn't talking about any kernel cache. I'm trying to figure out how, exactly, you've read my attempt at excessive clarity; it's not clear to me yet what you misread, since it seems like you're trying to correct some misunderstanding, but it hasn't worked because you haven't said anything that isn't already blindingly obvious. There is no "metadata relevant to the SSD innards" available. The md drivers do not have this information This is not an insight. The cache I'm interested in is tied up in how the SSD presents as a block device, but isn't implemented as a block device, as block devices are normally understood (wear levelling and remapping, hidden parallelism / striping, etc.). Yes, the FS cache can't help with this. Yes, the RAID implementation can't help with this. Of course. It's internal to the SSD. It's innards. I don't see what information you added.

Avernar 9y ago
I may have misread your original post but your hostility isn't helping to clarify things. Instead of replying back "I was talking about the SSD cache" you replay back with "Well, it could hardly be below, could it. Was there an insight you wanted to mention?" So instead of clarifying things you decided to be rude. Now that I know what you're talking about, let's try to answer your question. There are SSD controllers that don't use a RAM cache on the drive. It's not necessary for performance and doesn't do as much as on a HDD if present. The main benefit of a drive cache while reading is for read ahead. This is not needed for an SSD as it doesn't have to wait for the sectors to show up under the head. The only thing that will affect things is reading file system blocks from the same SSD page/block. The md code already does this. If the next block requested is after the last blocks read it will use the same SSD. If the block is from somewhere else then it doesn't matter if it comes from this SSD or that SSD. Access time will be the same.

Avernar 9y ago

I may have misread your original post but your hostility isn't helping to clarify things. Instead of replying back "I was talking about the SSD cache" you replay back with "Well, it could hardly be below, could it. Was there an insight you wanted to mention?" So instead of clarifying things you decided to be rude. Now that I know what you're talking about, let's try to answer your question. There are SSD controllers that don't use a RAM cache on the drive. It's not necessary for performance and doesn't do as much as on a HDD if present. The main benefit of a drive cache while reading is for read ahead. This is not needed for an SSD as it doesn't have to wait for the sectors to show up under the head. The only thing that will affect things is reading file system blocks from the same SSD page/block. The md code already does this. If the next block requested is after the last blocks read it will use the same SSD. If the block is from somewhere else then it doesn't matter if it comes from this SSD or that SSD. Access time will be the same.