本周阅读了FEMU中写入操作部分和部分代码需改。对于FEMU写操作部分，FEMU中采用NVME协议结合QEMU中的内存管理方式来实现I/O操作。我结合NVME 1.3协议和QEMU的相关文档进行项目中相关代码的阅读。然后简单构思了一下需要实现的部分和需要注意的点：写入缓冲区需要设置在NVME写操作从内存中获取数据并进行分页之后，同时写入缓冲区的设置是页对齐且分配了页号（即把写入缓冲区当成NAND Flash），这样从缓冲区进行读取就只需要先遍历写缓冲区，若未命中再从Flash中读取。实现上，本周只进行小部分的代码修改，准备下一周完成关于设置写缓冲区相关的代码修改。

上周忘了更新文档，这两周主要阅读FEMU代码，目前找到了FEMU的两个线程（数据存储和数据管理）之间的同步，目前正在测试部数据压缩部分，但因为不熟悉工具使用目前还在学习。下一步准备验证FEMU两个存储和管理两个线程的同步关系，进而实现管理的数据代码部分。

本周周一确诊甲流，本周大部分时间都在休息。不过这周学会了对项目的调试以及找到了项目中数据存储和管理两个部分同步的函数，并且进行了验证。接下来准备开展对于项目中数据管理部分相关的代码实现。

本周继续了上周的工作，对FEMU中数据管理部分进行开发，目前正在实现设置缓冲区并实现分类的部分。同时还阅读了下周要分享的FAST论文，并且制作了PPT准备下一周分享。下一周继续工程上的推进。

本周主要是进行数据布局函数的编写（正在实现re-bp方案），主要包括ssd_write函数和ssd_read函数，即修改ftl来进行数据布局的控制。遇到的问题包括（1）如何将页中的每一个压缩页取出来按照大小进行排序。（2）如何对压缩页进行失效标记，进而实现页失效的标记。ssd内压缩将失效数据的粒度从一个4kb的页降到一个压缩后的数据页。（3）gc时需要迁移有效的数据页到新的块。因此我在实现过程中引进一个反向映射的数据结构来实现ppn->lpn的1：n映射，即根据一个ppn可以获取里面的所有lpn（lpn通常为多个，一个物理页含有多个压缩页）。因为我们需要对压缩页按照大小进行排序，所以需要记录每一个物理页里面的压缩页的数据块，而数据块使用lpn来进行唯一标识（页级映射）。而且此前没有考虑到gc部分，gc过程需要将有效的压缩块迁移到空闲的压缩块，因此不仅要有ppn->lpn的1：n映射，还需要有一个valid标识位来记录哪一个压缩页是有效的，并且还需要将有效的压缩页拼接起来。目前正在进行这部分的代码编写，以及在编写过程中发现并解决问题。下一周继续进行代码编写，打算下一周可以完成代码编写以及进行正确性的验证和进行性能测试。

本周继续上周的工作，完成了对于re-bp方案的复现，不断调试后通过了正确性测试，不过本周服务器出了点小故障导致性能测试和复现剩下方案的工作被暂缓。同时在师兄的建议下开始着手撰写论文，目前还在写第一章节。目前的问题主要是性能测试的细节，包括需要测什么，怎么测。准备下一周跟师兄们沟通下测试方面的工作，同时准备完成对第一章节的撰写以及完成所有的复现工作并进行测试。

随着数据量不断呈现爆炸性的增长，压缩技术被广泛的使用以减少数据存储的成本。相比于会抢占CPU资源的主机端压缩和因块设备跟文件系统协议不匹配导致性能下降的文件系统端压缩，存储设备端压缩具有更好的性能。而存储设备硬件层上的压缩会引入“内部碎片”问题，即压缩后的数据页跟存储的物理页的大小不匹配而造成存储空间利用率的下降。为了降低“内部碎片”问题所带来的负面影响，需要一种合适的数据布局管理方案来管理压缩后的数据页。

为了研究合适的数据布局管理方案，首先进行对于RE-BP和COMPACTION这两个现有方案的复现。但这两种方案都难以兼顾读写性能和存储空间利用率。RE-BP方案由于破坏了压缩页的空间局部性并且在关键路径上引入了排序和查新插入的步骤而降低了顺序读取的性能。COMPATION方案则因允许一个压缩页存储在两个物理页上而降低随机读取的性能。为了减少上述因素对于性能的制约，设计了FOLLOW方案。首先，在存储当前压缩页时，优先满足当前压缩页同前一个压缩页存储在同一个页里，充分利用数据的空间局部性原理。其次，保证一个压缩页存储在一个物理页上，降低了读取时较高的尾延迟。最后，设计了一个读缓冲区来存储解压缩之后的数据页以减少访存次数。

实验结果表明。