[운영체제] OS 11장 Mass-Storage Structure

Mass-Storage (secondary storage)

---

• HDD나 SSD 같은 곳에 파일을 저장했다가 삭제도 했다가, 프로그램을 실행시키기 위해서 운영체제가 관리해 주는 운영체제의 서브시스템 중에 하나를 파일시스템이라고 한다.
• 운영체제의 파일시스템을 HDD나 SSD에 저장함. 그런데 어떤 경우는 RAM을 실제 disk처럼 사용해서 동작하는 시스템도 존재한다.
• 하지만 RAM disk는 전원을 끄고 다시 키면 데이터의 내용이 다 사라진다.

Disk Attachment

• PC는 다 Host attached를 사용한다.
• 연구실 같은 경우는 NAS로 네트워크를 연결해서 여러 PC에서 공유해서 사용한다. Network attached

Network-Attached Storage (NAS)

• client가 PC
• 여러 사용자가 공유 데이터를 사용할 수 있게끔 지원해 주는 방식이 NAS
• 그룹 별로 작업할 때 사용

Storage-Area Network(SAN)

• NAS와 SAN의 가장 큰 차이는 NAS는 파일 단위로 액세스, NAS장비를 윈도우에 연결할 때는 네트워크 드라이브라는 형태로 하나의 파일 시스템이 마운트 된 형태로 보인다. 거기에서 원하는 파일 단위로 액세스 한다.
• SAN은 블록 단위로 액세스 한다.

Storage Architecture

• IDE / SCSI : host attached
• SAN은 블록 단위로 액세스

HDD

 

HDD Structure

• 영화 한 편을 저장한다고 했을 때, 그럼 이 영화는 한 번 쭉 계속 읽음 (제일 윗 면), 그다음을 읽으려면 헤드가 안 움직이는 게 좋음 그러면 배치를 밑 면 해당 트랙에다가 한다. 그것도 다 했다면 밑 플레터의 윗 면에다가 배치. 이런 동심원의 트랙들의 집합을 실린더라고 한다.

 

• 헤드가 내가 원하는 트랙으로 이동하는 것이 seek, 기계적으로 움직여야 하니까 훨씬 시간적인 오버헤드가 크다.
• 내가 원하는 sector가 돌아서 내 밑으로 오는 것이 rotation, 거기서 데이터를 읽는 것이 transfer
• HDD에서 데이터를 읽는 요청들이 쭉 오는데 이것들의 순서를 바꿔서 더 효율적으로 디스크 read, write에 대한 성능을 높여줄 수 있도록 한 방법이 디스크 스케줄링

Disk scheduling

---

FCFS

• fair
• 도착한 순서대로 동작하면 많은 seek가 일어난다.
• FCFS는 seek라는 오퍼레이션을 고려하지 않았기 때문에 엄청나게 많은 seek가 많이 일어난다.
• 성능이 별로 좋지 않다.

SSTF

• 헤드의 위치에서 가장 가까운 실린더에 있는 것부터 먼저 처리하게 되면 seek 타임이 최소화가 된다. 따라서 성능이 좋아진다.
• SJF와 유사
• 디스크 같은 경우는 시간이 얼마나 걸릴지 미리 알 수 있다.

SCAN

• 디스크 요청이 트랙에 골고루 분포하기 때문에 헤드를 한쪽 방향으로 왔다가 갔다가 하게 되면 공평하기도 하고 우수한 성능으로 서비스할 수 있다.
• 엘리베이터 알고리즘이라고도 한다.
• 일반적으로 SCAN과 SSTF 알고리즘이 사용된다.
• 디스크 요청이 아주 많은 상황에서는 SCAN 알고리즘 사용되고 그렇지 않은 일반적인 경우에는 SSTF 알고리즘이 사용된다.

C-SCAN

• SCAN은 한쪽 방향으로 왔다 갔다 하는 것인데, 그렇게 되면 양 끝에 있는 애들이 상대적으로 우선순위가 낮아지는 효과가 발생함. 그런 문제점을 해결하기 위해서 왔다 갔다 하지 말고 한쪽 방향으로 가면서 처리를 하고 다른 쪽 방향으로 가면서 처리하는 것이 아니라, 쭉 갔다가 또 한쪽 방향으로 처리를 하는 형태
• 아무것도 하지 않고 쭉 오는 오퍼레이션은 쓸데없는 오버헤드가 되기 때문에 SCAN이 더 일반적으로 사용된다.

C-LOOK

• LOOK과 C-LOOK은 SCAN과 C-SCAN의 유사한 버전
• SCAN은 일단 끝까지 다 갔다가 반대 끝까지 다 가면서 처리하는 방법인데, LOOK은 일단 요청의 끝이 특정 부분까지 있다면 끝까지 가지 않고 거기서 바로 반대 방향으로 간다.

Selecting a Disk-Scheduling Algorithm

• 일반적인 상황(일반적인 웹서버 같은 경우)에서는 SSTF가 우수
• heavy load(VOD 같은 경우)인 경우 SCAN 사용

Disk Controller (I/O controller)

---

• 옛날에 운영체제에서 하던 기능이 지금 controller에서 다 이루어진다.

Swap-Space Management

---

• 윈도우즈는 일반 파일시스템에 파일로 저장, 리눅스는 별도의 파티션을 만들고 스왑 스페이스를 관리한다. 보통 리눅스를 설치할 때 메인 메모리의 2배를 스왑 스페이스로 파티션을 잡아놓고 리눅스를 설치한다. 윈도우즈는 별도로 스왑 스페이스를 잡지 않고 설치

RAID

---

• NAS에서 많이 사용한다.
• 하드디스크가 별로 안 비싸니까 많이 배치해서 2가지를 동시에 얻겠다. 
  • 1. reliability(신뢰도)를 높인다.
  • 2. 성능을 올린다.

Multiple Disks vs RAID

• RAID controller는 밑에 disk 4개가 있다고 생각하는 게  아니라 디스크가 1개가 있다고 생각하고 동작하도록 관리한다.
• 신뢰성을 높일 때 : 하나에 있는 내용을 옆에 똑같이 저장함 그러면 1번이 고장 나더라도 2번에 데이터가 남아있음(미러링, 쉐도잉)
• 성능을 높일 때: 디스크 블록을 0번부터 399까지 존재하도록 하는데, 데이터를 저장할 때 어떻게 저장하도록 하냐면
  • 1. 디스크 블록 0번을 4개에 나눠서 저장, 디스크 블록 0번을 읽어라 하면 4개의 디스크가 동시에 읽음, 1번을 써라라고 하면 4개의 디스크에다가 동시에 데이터를 쓴다. 저장을 할 때 줄처럼 여러 디스크에다가 나눠서 저장(data striping), 이렇게 하나의 블록을 여러 개의 디스크에 동시에 저장해서 동시에 데이터를 읽게 하는 striping을 bit-level data striping, parallelism, 하나의 요청을 모든 디스크가 나누어서 서비스
  • 2. 0번을 저장하면 1번을 그 옆 디스크에 저장하고 하는 방식, 0~3번을 읽어라 하면 4개의 블록이 동시에 읽힌다. 이것을 block-level data striping, concurrency, 4개의 요청을 각각 다른 디스크에서 처리
• 디스크가 HDD라면 한 번 seek 해서 많이 읽어야 성능이 우수하니까 block-level data striping이 성능이 더 높다.
• redundancy를 높이기 위해서는 parity, ECC, 미러링 방법이 있다.

RAID Levels

RAID 0

• 신뢰성은 고려하지 않고 블록 레벨 striping만 한다.
• secondary storage가 필요한데, 데이터가 날아가도 큰 문제는 없고 성능이 중요한 경우
• ex) VOD server

RAID 1

• 성능은 안 중요하고 신뢰성이 중요한 경우
• 데이터가 날아가면 큰 문제가 생긴다. 그래서 그때그때 복구할 수 있도록 미러링 하는 방식

RAID 2

• 하나의 디스크 블록을 4개의 디스크 블록에 나누어 저장
• 4개를 동시에 읽어가지고 하나로 합쳐서 하나의 블록이 된다.
• 성능을 높이기 위해서 비트 레벨 striping을 한 것이고 신뢰도를 높이기 위해서 미러링을 하면 디스크 용량이 많이 필요하니까 줄이기 위해서 ECC를 사용해서 줄인다.
• 0,1,2,3 4개 중에 3개의 디스크가 고장 나더라도 0번 4번 5번 6번을 가지고 이 내용을 복구할 수 있다.
• 디스크 2개, 3개 고장 나도 복구 가능
• 디스크 4개 고장 나면 복구 불가능

RAID 3

• 비트 레벨 striping, ECC 3개도 너무 비싸다. 그냥 하나만 parity로 사용하자.
• 디스크 0,1,2,3 중에 하나가 고장 나면 이 parity를 이용해서 0,1,2,4 디스크를 이용해서 원래 것을 복구하겠다.
• 4개 중에 2개가 동시에 고장 나면 복구할 수 없다. 복구를 위한 디스크를 하나만 쓰기 때문에

RAID 4

• 비트 레벨 striping이 성능이 안 좋으니 블록 레벨 striping을 하겠다.
• 디스크 블록을 0,1,2,3 스트라이핑 해서 저장을 하는데, parity 비트 하나를 사용해서 4개 중에 하나가 고장 나더라도 복구하겠다.
• 성능에 문제가 있다. read시에는 전혀 문제가 없는데, write를 한다고 하면, 예를 들어 1번 블록에 write가 되었다면 다른 경우에는 얘만 write 하면 되는데 4번도 같이 write 하게 됨 왜냐하면 parity가 바뀌기 때문이다. 그다음에 6번 블록을 write를 했다면 4번 블록의 두 번째 줄 P도 업데이트해야 함, 8번 블록이 업데이트되면 4번 블록의 세 번째 줄 P도 업데이트해야 함. parity를 다시 계산해서 저장해야 함.
• parity disk가 너무 바쁘다. write 시에 너무 바쁨. 이걸 개선한 게 RAID 5, 하나만 있는 P를 분산시킨다.

RAID 5

• 블록 레벨로 스트라이핑 하는데 parity 블록도 스트라이핑을 한다.
• parity에 대한 업데이트 요청도 여러 디스크로 분산이 된다. 그래서 성능이 좋아진다.
• 일반적인 상황에서는 성능이 좋고, 디스크 하나가 고장 나더라도 parity 블록을 이용해서 복구할 수 있다.
• 실제로 디스크를 운영해 보니, 디스크가 하나 고장 날 확률이 존재하는데, 이 하나를 복구시키기도 전에 또 다른 하나가 고장 나는 경우는 거의 없다.
• 많이 쓰인다.

RAID 6

• parity 비트를 2개 두는 것. 즉, ECC를 사용하는 것.
• 디스크 2개가 동시에 고장 나도 복구가능

RAID 0+1

• 블록 레벨 스트라이핑으로 성능을 높이고 미러링
• 이때 블록 레벨 스트라이핑을 먼저 미러링 하는 방법
• RAID 0을 먼저 하고 RAID 1을 한 경우
• 디스크 2번이 고장 나면 왼쪽 RAID 0 이 고장 난 거, 즉, 0,1,3은 디스크가 고장이 안 났지만 왼쪽 RAID 0이 동작을 안 하니까 그다음부터는 전부 오른쪽 RAID 0에서 처리하니까 4,5,6,7만 동작하고 0,1,3은 사용이 안된다.

RAID 10 (or RAID 1+0)

• 미러링 한 것들을 블록 레벨 스트라이핑
• RAID 1을 먼저 하고 RAID 0를 한 경우
• 2번이 동작하지 않으면 두 번째 R1 만 동작하지 않는 것임 다른 애들은 다 동작한다. 즉, 디스크 하나가 고장이 났을 때 RAID 1+0인 경우에는 그 디스크를 제외한 모든 디스크가 동작을 한다. 그래서 RAID 1+0가 RAID 0+1보다 성능이 우수하다.