SSD EFTL 改进日志

发现如果使用块数太少，根本不会调用GC ，也就是没有erease操作，10000不行

从parv文件里可以看出一共有1G = 512k * 2097152 扇。

而flash.h中定义一块64页，一页4扇

故 = 524288 页 =  8192块（实际上还有extra block ，nand_blk_nom = 8448

因此考虑1：修改parv文件，将块号改少2：用更长的trace，3：初始化flash时，将其中部分置为invalid

后来在flash.c->nand_page_read()里发现它使用了固定的8448，可以得知，不能随便改动parv文件，

出现读越界，且物理扇号是-4，估计是opagemap映射出错

更新的过程似乎米有对

28号找了一天，晚上7点在椅子上睡了一觉，醒过来冷静观察，终于找到错误了，原来是不命中的括号位置方戳了，造成如果命中，不进行读写操作！！当然就有可能使本来已经写过的页却无效

同时也暴露出源程序的一个漏洞：如果读无效页，应该给一个提示而不是因为越界而终止。

因此我做了改进，在flash.c ->nand_page_write()/read中加了如果越界就赶紧return。

为了观察命中率，我在flash.h中定义了hit和not_hit,在flash.c->nand_flash_reset()中初始化，在ssd_interface.c中取得cache命中率，在flash.c ->nand_stat_print()里打印出来

可以知道flash.*中记录的是总信息，在ssd_interface.c中记录的是一次任务的信息

Extending SSD Lifetimes with Disk-Based Write Caches

为了改变patch_num ,把它定义位变量放在ssd_interface.h中去了，这样外界可以随便定义它的值

关于disksim不能通过部分trace  照此说明，把trace中的reqtime*100，解决

瞎折腾不如睡一觉！！！

发现还与请求时间间隔有关系，间隔越短我们的算法越有优势，甚至可达8倍以上！！！io响应时间与队列长度的关系

我发现那个io响应时间变数非常大，上层io请求越快，dftl的io响应时间越糟糕，而我们的eftl越有优势，我用一个finacial trace测试，eftl的io响应时间甚至可以只有dftl的1/8！！

我不清楚io响应时间与请求频率的关系似乎是请求越快，队列越长？

现在存留的一个不得不面对的问题：我们的eftl模拟比别人更耗时，因为要更多的对cache进行遍历。现在是否可以忽略那些时间呢？？

单独测试多表调入，发现finacial trace下命中率大大提高，但是读写次数反而增加！！。

后来认思考，虽然命中率提高，但是不命中开销增大，因为一旦不命中，就需要更新（读+写）0-64次！！而原来的不命中开销是0-1次！！！

看来有一个命中率*不命中开销的折衷点。

我的办法是：为了减少不命中开销，可以只挤出去一页中的n个age最小的表，而不是死板的挤出64个。这样不命中开销就不会增加！！

为了不至于找一页中age最小的表算法复杂度太高，我认为既然有连续性，如果某个页不用，它周围的页多半也没用，因此只需要把age最小的页的周围（映射在同一页中）的页的映射调出。这正好可以利用附带更新的那个遍历！

其实真实操作的时候，没有必要想这么多，就是判断vic_page_num不能为2，为2的时候便不再调出（当然还有一个调出最大上限）

然后顺便再对调入优化，不一定死板地调入8个，而是从一页中调入，尽可能把cache填满

但是这样命中率确实低了。我又想到，其实很大一部分请求的扇数介于1-8之间,即请求连续的两页，因此对连续的两页调入对命中率的提高必然会有很大贡献。

看来连续性有：1,请求内的绝对连续性 2.请求间的跳跃连续性

考虑到有时候会调出多个表也满足同一页，为了既要满足绝对连续性又绝不能调出2页，要同时满足：1，如果blk_cout > 1那么就满足他调入连续的页;2.绝不能调出2页。

方法有二：1.如果没有绝对连续性即blk_num = 1，则预留2个空间，有绝对连续性的时候使用。2.如果有绝对连续性，就强制要求挤出足够的空间，如果老实的调出不够，遍历一遍cache，总能找到在一页中的。也不能放弃绝对连续性

给出的提示是，即使考虑跳跃连续性，

关于I/O流。调度太多代价高。调度太少命中率不高，为什么不高？因为它IO流的连续性其实也有跳跃性！！

需要分析IO流长度和，跳跃长度。

发现我的算法模拟时间太长了。想法设法改进。求是不是在同一页/512可以用>>9来表示

 In the case of random streams, all requests must be tracked since
it is difficult to determine whether these requests are from a sequential stream with a low arrival rate or
from a random stream. Hence, requests from random streams can fill up the sequential stream tracking
cache quickly. The size of the tracking cache must be large so that requests from sequential streams
reside in the cache until there is a hit. Setting aside limited disk array cache space for a large tracking
cache would reduce the size of the prefetch cache, thus lowering the prefetch hit rate. However, a key
observation regarding the tracking mechanism is that current request addresses have to be compared to
past request addresses. Thus, the tracking cache stores only request addresses and not request data, so

我可以track 映射所在页（数量极少）来判断是否是sequencial