**感謝作者無私分享
《一》linux發展到現今，在fs目錄下我們可以看到形形色色的檔案系統，眼花繚亂的同時首先需要回答的問題是，為什麼會有檔案系統這個東西呢？我想如果能搞清楚這個問題，會幫助大家更好的理解檔案系統，那麼我就嘗試著來模擬一次檔案系統的演進過程，於是，我們來到了那一天，那天之前，人們還沒有檔案系統的概念。
友情提示 : 下面將在荒誕的場景下演進人類合理的訴求
神說，要有光，於是，光照大地
神說，要有風，於是，風動四方
神說，人類要記住神，於是，有了傳說
神說，怕你們忘了，得記下來，於是，有了文字，資訊被儲存在石板上，竹片上，紙張上，硬碟裡，flash中
當資訊能存在硬碟中的時候，人類如獲至寶，如此大的儲存量，我們能裝下全世界圖書館的館藏，於是，我們想先放一套盜墓筆記進去。
好嘞，於是，我乙個字乙個字的將精彩的內容順序儲存在硬碟中，終於，全套的盜墓筆記被儲存在硬碟中了，還沒來得及高興，就傻眼了，我不想看秦嶺神樹，怎麼辦，這並難不倒我，略加思索，就能想到解決方案，因為是順序儲存的，從開始的地方一直讀下去，當恰好跳過秦嶺神樹章節內容的時候，就做乙個標記，記錄已經跳過的位元組數，下次再看的時候，就直接讀到硬碟對應的位置即可，經過一番努力，我找到了並把這個位元組數寫在了一張紙條上，以便下次可以直接讀取，避免一次次的遍歷。
後來，我開始有點不耐煩了，因為這張紙條裡面的內容越來越多，比如最後一章的位置，終極第一次出現的位置等等，有時我甚至記不住我需要尋找的標記是否在紙條中了，終於有一天，這張紙條丟了，我只能呵呵並且從心底認為，僅僅是順序儲存無法滿足我的需求，我需要管理這些內容。
我想，最起碼我需要能把全套的盜墓筆記分為8本書吧，只要根據書名，比如邛樓石影，我就立刻能找到對應的內容，我立刻想到了最簡單的解決方案，仍然使用順序儲存，只不過在內容錄入的時候，給每本書分100mb的儲存空間，這樣我如果想看第7本，那麼直接從600mb偏移開始即可，那麼一套盜墓筆記只需要800mb就可以儲存，但是，我很快又有了乙個更優的方案，在每本書的100mb可用空間內，再進行細分，給每章節進行劃分，假設每本書有50章，那麼每章節就是2mb空間，這樣每章節按照2mb對齊，我要找第6本書的第30章節，就是(500 + 29 * 2)mb 偏移，我甚至都有點洋洋自得了，簡單的設計一下就可以再也不用依賴那張小紙條(已遺失)了。
但是，很快我又遇到了新的挑戰，因為這塊硬碟不是我的，開始說好的800mb沒有了，我被要求只能使用8mb來儲存全套的盜墓筆記，原先的設計繼續使用，每章只能分到20kb，這樣有些內容多的章節會越界，而有些內容少的章節又不夠飽滿，那些沒有被利用起來的空間此時顯得的是那麼的珍貴，於是我開始了小心翼翼字斟句酌的重新設計。
看起來，順序儲存是最節約空間的，那麼只有將小紙條(已遺失)的內容也儲存在硬碟中了。於是，喝下一罐可樂後，我發覺將章節抽象成乙個章節類是乙個不錯的注意，每個章節是該類的乙個物件例項，類成員包括章節名稱，章節起始位置，章節字數，每個物件都64位元組對齊，這樣400章的索引資訊只需要25kb即可完成儲存，我大大方方的將全部的章節類物件儲存在8mb的前32kb區域，後面剩餘的全部順序儲存內容，就這樣，隨著需求的不斷增加，我的設計也漸漸開始有檔案系統的影子了，儘管我並不知道，但是一切就這樣發生了，是那麼的自然。
《二》距我將全套盜墓筆記成功儲存在8mb空間裡已經過去了19天58分鐘32秒，我漸漸發覺更高、更快、更強的絕不限於奧運精神，也充分體現了人類貪婪的本質，無盡的需求催生出這光怪陸離的大千世界。
就在今天下午，我得到乙個通知，要麼繼續使用連續的儲存空間，但是只能有4mb，要麼去使用不連續的儲存空間，總量可以仍然是8mb，那一刻，我的內心反而是平靜的，因為我知道，這就是現實，乙個不夠優秀的系統是無法滿足各種刁鑽的需求的，並且我並不想丟掉一半的盜墓筆記，所以我必須使用不連續的儲存空間，乙個不算壞的訊息是，就算是不連續，但是每塊最小也有2048位元組，並且連續的儲存空間是2048位元組對齊的，還有什麼好說的，擼起袖子加油幹，這很2017。
當時我的腦海中，浮現出了星空的影象，天頂中每顆閃爍的星代表的就是一段文字，我要怎麼將它們串在一起呢？我想，首先要解決的是識別問題，即眼前的這顆星屬於哪本書？是的，我需要星的索引資訊，每條索引資訊對應著一段可儲存的空間，記錄空間在硬碟中的偏移，長度，內容是屬於哪本書，對應內容在書內的偏移，這樣通過索引資訊就可以在硬碟中找到儲存著的盜墓筆記的片段了，於是有了如下的設計，
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資料塊就成為了串起整部盜墓筆記的那個入口
為什麼選擇裸裝置，為什麼選擇檔案系統
字元裝置 塊裝置 裸裝置 raw裝置 第一，字元裝置是指在i o傳輸過程中以字元為單位進行傳輸的裝置，例如鍵盤，印表機等。請注意，以字元為單位並不一定意味著是以位元組為單位，因為有的編碼規則規定，1個字元佔16位元，合2個位元組。在unix系統中，字元裝置以特別檔案方式在檔案目錄樹中佔據位置並擁有相...
為什麼會有異常
為什麼會有異常？為了使程式更好的執行。很多教程裡都舉例 10 0 0不能作為分母 這樣會報異常。我常想，那麼為什麼不用if else來解決這件的問題。然而，真實的情況是 我們並不知道未來會發生什麼。比如說，電腦乙個資料夾路徑，本來我用的好好的，突然有一天，來了乙個人，將這個檔案剪下走了，我並不知道這...
JS 裡為什麼會有 this
這篇文章是從語言創造者 js 之父的角度 來思考 this，我之前那篇講 this 的文章是從使用者的角度寫的。假設我們有乙個物件 var person saybye function 這個 person 物件有 name 和 age 屬性，還有乙個 sayhi 方法，現在的需求是 呼叫 perso...