5 ms·

Let me clarify. All the VFS caches are above the md driver. The cache we care about, the buffer cache, is not below the md driver. You'd need some kind of ca

Let me clarify. All the VFS caches are above the md driver. The cache we care about, the buffer cache, is not below the md driver. You'd need some kind of cache below the md driver to cache "metadata relevant to the SSD innards". Since there isn't one therefore there can't be a penalty due to caching to switch between SSDs in a mirror. That answers your question. But since you want an insight, here's one for you. There is no "metadata relevant to the SSD innards" available. The md drivers do not have this information. I wish they did. When I was still playing with the md code I'd love to know the block and page sizes of the drives. But that information is two bytes. Not really something that would need a cache.

barrkel 9y ago
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.

barrkel 9y ago

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.