上回說到了磁碟的一些特性，感覺不說說檔案不太妥。以及對比檔案系統和raw device的優劣。

   在目前的各種檔案系統中，JFS是一種比較適合大規模資料處理的檔案系統，但常用的依然是ext2,ext3. 不同的檔案系統受到特定業務的影響在保持通用的前提下，各有側重，下面談談主要優化需要考慮的問題：

   檔案系統都要求整塊讀寫磁碟的，按照block size = 4K為例，如果需要在一個塊上寫1K資料，則首先需要從磁碟將這個塊讀入記憶體，在記憶體中寫入1K資料（看做是合併塊中其他資料），再回寫磁碟。顯然如果寫的是4K資料，且恰好是寫在一個塊上的，則系統就免去讀入記憶體和合並的開銷，因此我們一般一次寫入儘可能多，例如寫入10K，則有可能是前兩個是整塊寫，而後一個是半塊寫，半塊寫的額外代價攤下來就不顯的很多。
 
   由於尋道時間是磁碟訪問代價中最大的一塊，而且道次跳得越大代價越高，因此我們希望檔案所包含的塊（fileplace命令檢視）儘可能連續，而檔案系統也是這麼做得，但遺憾的是無論怎樣，檔案也會向不連續的方向發展，特別是系統中各種檔案大量建立，追加，刪除後。因此在磁碟長期使用後，明明檔案是順序讀寫，但實際上已經是隨機讀寫。這叫做檔案碎片。

   如果事先知道結果檔案的大小預分配是很好的選擇，怎樣快速建立一個大檔案呢？
   這裡有個快速的方法：
   int fd = open("./file", O_RDWR|O_CREAT|O_TRUNC,00777);
   off64_t set = 5*G;
   lseek64(fd,set,SEEK_SET);
   write(fd,"/0",1);
   然而遺憾的是，這樣的做法分配的是一個空洞檔案（稀疏檔案），這個貌似5G的檔案大小其實並沒有申請到真正的磁碟塊，只有在實際寫入的時候才會分配，BDB的臨時檔案db00x就是這麼創建出來的，這也是BDB慢的一個重要原因。
   怎麼快速建立一個真正的大檔案呢？我留一個問題，請大家回答。
   另外附帶的一個問題是，為什麼寫磁碟比讀磁碟要慢，慢在哪裡，如果去掉這一部分是否可以加快寫的速度？
  
   檔案系統無論如何也很難滿足業務上的需要，大部分情況下需要直接處理raw device。或者說自己按照業務需要對裸裝置進行格式化，建立自己的特定讀寫系統。
   比如這樣一個場景，需要對每一天的資料(key,value pair)寫入raw device, key都是定長而value大小各異。如果把key，data 看做二維，看成如下矩形:
  
   date(近 ---------------------------->遠)
   -------------------------------------------
key|  A |  B
   |----|---------------------------------C
   |    |
   |    |
   -------------------------------------------
   不難理解越近的日期訪問頻率越高(A區訪問的概率遠大約B區，A區為熱區），而某些key會在一個長的日期範圍內長期使用(線C是訪問熱點，叫做熱線吧）。

   首先我們系統資料按照日期的順序進行存放，條件允許的話，越近日期的資料放在距離raw device 零位置越近的區域，資料在順序讀寫時均不會出現躍2個磁軌以上的情況。在業務上這種順序讀寫是顯然的，大量的，資料按天生產，按天處理寫入，使用（讀）也多為按天處理。隨機讀寫也多發生於A區，A區所佔的道次比較有限，因此跳躍的道次也一般較少。不跳的概率較高。C線也很有趣，比如順序讀取某個key，全部天數的資料，則無論由近讀到遠或者由遠讀到近，道次都好像電梯一樣升降，不會來回跑，因此開銷也是很小的，當然與A區相比，想盡可能不跳只轉是不可能的了。

   但如何解決value大小各異的問題呢？外部需要哪些索引呢？raw device怎麼copy呢，怎麼備份呢？在容量不夠時如何擴充套件呢？在享受了raw device的好處後，還需要解決很多這些細節的問題，需要在實際的環境中更多實踐。