# Massive Storage Management ###### tags: `IT鐵人` 其實這塊要講的就是有關Disk的內容,前面說明Disk的時候就有提到他的構造以及Disk Access Time,也有一張專門說明各種RAID的差別,如果不記得的話底下有幾隻圖片可以複習。 |Hard Disk構造|Disk Access Time|RAID| |-|-|-| |![](https://i.imgur.com/BoOsF92.png)|![](https://i.imgur.com/51LNiTB.png)|![](https://i.imgur.com/ewKLMO7.png)| ## Disk Free Space管理方法 這篇第一件事情要講的事情是OS如何管理空閒的空間,主要有兩種方式,其中一種又會延伸出另外兩種做法,以下一一解釋: ### Bit Vector ![Uploading file..._04mfils1w]() 我們用一堆Bit來表示每個Block是否空閒,1代表正在被占用,0代表目前空閒。 這種做法簡單又很好尋找連續的Free Space,但是不適合用在大型的Disk,如果Block數量太多,管理的空間就要很大,甚至只能放在Disk中無法放在Memory,效率會大幅下降。 ### Link List ![](https://i.imgur.com/lG8th1S.png) 這是一種熟悉的資料結構,每個node會記錄下一個Free Space的位置。 這樣子的做法就適合用在大型的Disk,因為只會使用空閒的Block數量,實施方式也不麻煩,不過不太適合用在尋找連續的Free Space,也不太好尋找大量的Free Space。 基於以上的缺點,Link List的做法有兩種延伸做法,分別為Grouping以及Counting。 ### Grouping ![](https://i.imgur.com/JSqk76c.png) 不讓一個node只有一個Free Sapce的位址,而是存放多個Free Space位址,如此一來找尋大量Free Space的速度就增加了。 ### Counting ![](https://i.imgur.com/sQA2V6N.png) 另一個是著重於找尋連續的Free Block,在紀錄Free Sapce位址時,也順便紀錄後面有多少個Free Space,這樣找尋連續Free Block就比較簡單。 雖然上面的圖說的是檔案的起始位置跟大小,不過概念是一樣的。 ## Disk Scheduling Algorithm 由於Process會發出許多Disk的需求,這時候OS就要負責哪個需求先處理,以下用表格簡單說明。 |法則|作法|效益| |-|-|-| |FCFS|First Come First Serve,誰先來誰就先處理。|可能導致讀取頭需要左右來回讀取,Seek Time較長。但簡單實施,並且公平。| |SSTF|Short Seek Time First,找距離目前最近的先處理。|Seek Time變少,但不一定最佳,並且可能發生Starvation(一直有讀取頭附近的需求,遠處的輪不到)。 |SCAN|讀取頭來回跑到底,經過有需求的位址就回傳資料。|效果不錯,公平且適合用在大量需求的狀況,但走到盡頭有點浪費時間。| |C-SCAN|類似SCAN,不過永遠回到開頭往後掃描。| |Look|類似SCAN,不過掃到最後一個需求位置就往回折返。|可以省去跑到底的時間。| |C-Look|類似Look,不過掃到最後一個需求位置之後,直接跳到開頭繼續掃描。| ## OS結束啦~ 我們的OS部分就到這邊啦~也只剩下最後一篇了,最後一篇會介紹一個資安的新聞,並且跟各位分享怎麼避免被偷資料。 |上一篇|下一篇| |--|--| |[Virtual Memory](https://hackmd.io/@dZfCcN4hT8aUuDPv3B8CWQ/S1HbjAs4Y)|[資訊安全宣導](https://hackmd.io/@dZfCcN4hT8aUuDPv3B8CWQ/B1XiSLWrK) ![](https://i.imgur.com/JrBpVjp.png)
×
Sign in
Email
Password
Forgot password
or
By clicking below, you agree to our
terms of service
.
Sign in via Facebook
Sign in via Twitter
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Wallet (
)
Connect another wallet
New to HackMD?
Sign up