距我將全套盜墓筆記成功保存在8MB空間里已經過去了19天58分鐘32秒，我漸漸發覺更高、更快、更強的絕不限于奧運精神，也充分體現了人類貪婪的本質，無盡的需求催生出這光怪陸離的大千世界。

就在今天下午，我得到一個通知，要么繼續使用連續的存儲空間，但是只能有4MB，要么去使用不連續的存儲空間，總量可以仍然是8MB，那一刻，我的內心反而是平靜的，因為我知道，這就是現實，一個不夠優秀的系統是無法滿足各種刁鉆的需求的，并且我并不想丟掉一半的盜墓筆記，所以我必須使用不連續的存儲空間，一個不算壞的消息是，就算是不連續，但是每塊最小也有2048字節，并且連續的存儲空間是2048字節對齊的，還有什么好說的，擼起袖子加油干。

當時我的腦海中，浮現出了星空的圖像，天頂中每顆閃爍的星代表的就是一段文字，我要怎么將它們串在一起呢？我想，首先要解決的是識別問題，即眼前的這顆星屬于哪本書？是的，我需要星的索引信息，每條索引信息對應著一段可存儲的空間，記錄空間在硬盤中的偏移，長度，內容是屬于哪本書，對應內容在書內的偏移，這樣通過索引信息就可以在硬盤中找到存儲著的盜墓筆記的片段了，于是有了如下的設計，

book_name用來存儲書名，hd_ofs存儲這段存儲空間在硬盤中的偏移，file_ofs存儲這段存儲空間存儲的內容在書中的偏移，chunk_len存儲這段存儲空間的長度，看起來是能工作的，那么這樣的設計夠不夠好呢，答案顯然是需要拿出工匠精神再來打磨一下了。

book_name，這里看起來很糟糕，如果書名很長則無法存儲完整，如果書名很短則浪費了存儲空間，這里真的需要存儲一個書名嗎？按照我的需求，盜墓筆記全套是8本書，那么第一本書，我這里記錄1即可，依次則是2,3,4,...，我只需要數字就可以進行區分，于是新的設計出現了

但是，新的問題又出現了，我能夠通過一個個的index對象找到數據塊，但是我該如何找到這些index對象呢？由于每個index對象占用12字節，那么將index搓堆存在一個只存儲index的數據塊內，那么一個塊能存170個index，就像下面這樣

很好，現在有了一個index塊，那么170個index最多只能映射(170 * 2048)字節(340KB)的內容，可我要存儲的盜墓筆記不止這么點內容，所以還需要更多的index塊

很好，現在有了更多的index塊，我能通過index找到想要看的內容，但是index塊也是不連續的，我要如何找到index塊在哪里呢？其實，我對之前每個數據塊填充170個index對象已經感覺難受了，因為170個index對象只使用了2040字節，這樣一個數據塊就有8字節的浪費，如果這8字節用來存儲另一個index塊在硬盤中的偏移位置，那么index塊之間就能串聯在一起，而我要做的就是找到那個入口

經過了兩頓燒烤的談判，我終于贏得了硬盤第1024個數據塊的永久使用權，于是第1024數據塊就成為了串起整部盜墓筆記的那個入口