SSD内部维护了一张映射表（Map Table），HOST每写入一个Host Page，就会产生一个新的映射关系，这个映射关系会加入（第一次写）或者更改（覆盖写）Map Table；当读取某个Host Page时， SSD首先查找Map Table中该Host Page对应的Physical Page，然后再访问Flash读取相应的Host数据。

一张Map Table有多大呢？这里假设我们有一个256GB的SSD，以4KB Host Page为例，那么一共有约 64M（256GB/4KB）个Host Page，也就意味着SSD需要有64M大小的Map Table。Map Table中的每个Entry存储的就是物理地址（Physical Page Address），假设其为4Byte (32 bits) ，那么整个Map Table的大小为64M*4B = 256MB。

对绝大多数SSD，我们可以看到上面都有板载DRAM，其主要作用就是用来存储这张映射表。也有例外，比如基于Sandforce主控的SSD，它并不支持板载DRAM，那么它的映射表存在哪里呢？SSD工作时，它的绝大部分映射是存储在FLASH里面，还有一部分存储在片上RAM上。当HOST需要读取一笔数据时，对有板载DRAM的SSD来说，只要查找DRAM当中的映射表，获取到物理地址后访问FLASH从而得到HOST数据.这期间只需要访问一次FLASH；而对Sandforce的SSD来说，它首先看看该Host Page对应的映射关系是否在RAM内，如果在，那好办，直接根据映射关系读取FLASH；如果该映射关系不在RAM内，那么它首先需要把映射关系从FLASH里面读取出来，然后再根据这个映射关系读取Host数据，这就意味着相比有DRAM的SSD，它需要读取两次FLASH才能把HOST数据读取出来，底层有效带宽减半。对HOST随机读来说，由于片上RAM有限，映射关系Cache命中(映射关系在片上RAM)的概率很小，所以对它来说，基本每次读都需要访问两次FLASH，所以我们可以看到基于Sandforce主控的SSD随机读取性能是不太理想的。

继续回到之前的SSD写操作。当整个SSD写满后，从用户角度来看，如果想写入新的数据，则必须删除一些数据，然后腾出空间再写。用户在删除和写入数据的过程中，会导致一些Block里面的数据变无效或者变老。如下图所示（绿色小方块代表有效数据，红色小方块代表无效数据）：