idea: content-aware buffer manager

以下稱  content LRU  為 CLRU，也就是  list 上只串著 FingerPrint (FP)  ，search 時只比對 content。和傳統的LRU比較(i.e., ALRU ，也就是 list 上只串著address和content，search 時只比對 address
有DEDUP功能的系統，buffer中會有   CLRU 和 ALRU

----------------------------
idea 1
    hot-content first LRU :
    rationale : CLRU中的某 content 很 hot ，那ALRU中可以不必放此content了，因為有高機會會被de  掉。

idea 2
    RAM放FP較好，還是放content較好?    → 分析這一刀該切在那
    maybe，也可以adaptive調整。

EXlru

http://home.ustc.edu.cn/~shil0704/conf/PDF_EMSOFT_11_1.pdf motivation : lack of page-level access information in the block based WBC ---------------------- 點出  以block-level為 LRU排序的單位 的壞處。     (a) Slow retirement of large cold blocks          只因少數page更新，而讓整個blk(連同cold pages)都搬到MRU去     (b) Early eviction of small hot blocks          ex. 假設 block A有31個pages ，每個page都只被update 1 次                      block B有3  個pages ，每個page都被update 10 次                 誰該留在buffer中久一點??   應該要是 B -----------solution----- add page-level access information (VPN, Data, Hit_count, Request_number)   自己推出一套計算權重的方法來決定 eviction order

temp

Understanding Performance Interference of I/O Workload  in Virtualized  Cloud Environments

Easy and Efficient Disk I/O Workload Characterization in VMware

http://blogs.oracle.com/henk/entry/swat_a_disk_and_tape   swat workload analyzer

Libtrace: A Trace Capture and Processing Library

指標...

1.  int *a[10]
2.  int (*a)[10]

自己理出的規則如下:  
array前面是array的名子

int *a[10] ，a是array的名子，然後這個array放的是 int *
int (*a)[10]，(*a)是array的名子，然後array裡面放的是 int 

沒人看

也許這是一個沒人看的blog
也許這正合我意，我該不斷的學會alone
我不擅獨，所以我要練習。

disksim SSD容量 與 "Max Addressable LBA in SSD Trace File"

SSD容量的算法，如下:

---

Pages Per Block         = 64
Blocks Per Plane        = 2048
Planes Per Element      = 8
Page Size               = 8 sectors = 4 KB

----

Pages Per Single Element 

= 1 (Element) * 8 (planes) * 2048 (Blocks) *64 (Pages) = 1048576 Pages

那，trace裡面的 Block number 最大可以定址到多少?

先換算成sector(file system block)

1048576* 8 = 8388608

the MAX Addressable Sector = 0 .. 8388607 Sectors

disksim 中 "I/O trace time scale" 參數

disksim在parv檔提供這個參數，讓user可以調整trace的特徵(如 arrival time, request size, location etc.)
但是網友發現 在disksim source中根本就把 IO trace time scale寫死，程式碼如下:


在 disksim/src/disksim_iosim.c下:

void iosim_initialize_iosim_info ()
{
    disksim->iosim_info = DISKSIM_malloc (sizeof(iosim_info_t));
    bzero ((char *)disksim->iosim_info, sizeof(iosim_info_t));

    /* initializations that get remapped into iosim_info */
    ioscale = 1.0;    /**************LOOK HERE************/
    last_request_arrive = 0.0;
    constintarrtime = 0.0;
}

也就是說，想改變request的arrival time，只能在上面code中改。

原文:https://sos.ece.cmu.edu/pipermail/disksim-users/2007-August/000184.html