27. Disk Management & Scheduling 1 : 디스크 관리와 스케줄링
Disk Management
디스크를 관리하는 최소의 단위는 섹터이다.
디스크는 원판으로 되어있고, 동심원 각각은 조각조각으로 나뉘어져서 관리가 되고 있는데 그 조각이 섹터라고 한다.
그래서 디스크의 최소 단위는 섹터(sector)이다.
디스크 섹터는 디스크 내부에서 관리하는 단위고, 섹터에서 데이터를 읽고 쓰라는 건 디스크 컨트롤러가 관리하는 것이다.
디스크 외부에서 디스크를 접근하는 단위는 로지컬 블럭(logical block) 단위로 디스크를 바라본다.
컴퓨터 호스트에서는 디스크를 접근할 때 로지컬 블럭 단위로 접근하는 것이다.
로지컬 블럭은 1차원 배열로 구성되어 있다.
그래서 컴퓨터 호스트에서 어떤 디스크에서 읽고 쓰라고 할때 '배열 몇 번째 요소를 달라'고 요청하는 거다.
디스크 컨트롤러는 밖에서 요청하는 배열을 어떤 원판 -> 어떤 트랙 -> 어떤 조각에 로지컬 블럭을 위치시킬지 결정하는 거다.
로지컬 블럭 - 섹터는 서로 매핑되어 있는 관계
섹터 0번은 로지컬 블럭 0번에 해당하는 건데 이건 정해진 약속이다. 디스크의 가장 바깥쪽 실린더의 첫 트랙의 첫 섹터가 어떤 파일 시스템을 쓰든 간에 부팅과 관련된 정보가 저장된다.
Physical formatting
- 읽고 쓸 수 있도록 디스크를 섹터 단위로 나누는 과정을 피지컬 포맷팅(low-level formatting)이라고 한다.
- 요즘에는 하드 디스크의 용량이 커져서 시간이 오래 걸리기 때문에 피지컬 포맷팅이 다 되어서 나온다.
- 각각의 섹터는 실제 디스크 외부에서 요청하는 로지컬 블럭을 저장하기도 하지만, 그 외의 것을 저장하기 위한 공간이 따라 붙는데 그것을 header와 trailer라고 한다.
- 결론적으로, 섹터는 header + 실제 data(512bytes) + trailer로 구성되어 있다.
- header와 trailer에는 sector number, error-correcting code(ECC, 데이터를 아주 작게 요약한 코드)가 저장되어 있다. 마치 메타 데이터처럼 디스크를 읽고 쓰기 위한 부가적인 정보가 header와 trailer에 저장되는 것이지
- 추후에 디스크 컨트롤러가 bad sector가 났는지 아닌지 에러 검출 및 수정에 ECC에 들어있는 코드가 사용되기도 한다.
Partitioning
- 포맷팅이 끝난 후 섹터 영역을 묶어준 후 하나의 독립적인 디스크로 만들어주는 과정
ex. 하드 디스크 하나를 사서 C드라이브, D드라이브로 나누는 것
- 운영체제는 물리적인 디스크가 아닌 논리적인 디스크를 독립적 디스크로 취급한다.
Logical formatting
- 파티션이 끝나고 나면 파일 시스템으로도, swap area로 쓸 수 있는데 파일 시스템으로 설치해서 만드는 것
- FAT, inode(리눅스의 경우)
FAT
Booting
- 파일 시스템 안의 운영체제가 메모리에 올라와 부팅이 되는 경우
- 부팅절차
0. 메모리는 전원을 켜면 비어 있는 상태
1. 메모리는 CPU만 접근할 수 있고, 하드 디스크는 메모리에 접근할 수 없음
2. 근데! 메모리 중 전원이 나가더라도 내용이 유지되는 ROM에 부팅을 위한 아주 간단한 small bootstrap loader가 있는데 전원을 켜면 CPU 제어권이 ROM의 해당 loader를 가리키게 된다.
3. 하드 디스크의 0번 섹터 내용(부팅과 관련된 섹터)을 메모리에 올리고 실행하라고 지시한다.
4. Boot block을 메모리에 올려 실행하게 되면, 파일 시스템에서 운영체제 커널의 위치를 찾아서 메모리에 올려 실행하게 된다.
5. 부팅이 시작되게 된다!
Disk Scheduling
Access Time
디스크에 접근하는 접근 시간이며, 크게 세 가지 시간 요소로 구성
1. seek time
디스크 헤드가 읽고 쓰는 요청을 한 안쪽 트랙/실린더에 있으면 그쪽으로 이동하게 되는데 그것에 걸리는 시간을 일컬음
이 seek time이 가장 오래 걸리고, 아무래도 기계장치이다보니 시간 소요가 오래 걸리게 된다.
그래서 한 번 seek했을 때 많은 양을 읽으면 그게 효율적이라고 함
2. Rotational latency
디스크는 항상 회전하고 있고, 요청한 내용이 헤드에 회전해서 도착해서 오는 시간을 말함
seek time보다는 1/10정도 적은 시간 규모
3. Transfer time
실제로 데이터를 읽고 쓰고 전송하는 시간
굉장히 작은 시간을 차지한다.
Disk bandwidth
단위 시간 당 전송된 바이트의 수를 말한다.
이게 높아지려면, 즉, 디스크가 효율적으로 동작하려면 seek time을 줄이는 게 좋다.
Disk Scheduling
그래서 이 스케줄링이 필요하다. 가능한 seek time을 줄여서 disk bandwidth을 높여보자!
따라서, 요청이 들어오는 순서대로 처리하는 건 비효율적이다.
Disk Scheduling Algorithm
디스크 내부에서 구현되는 알고리즘이 아니라는 것!
운영체제 쪽에서 구현되는 것이라 실린더 위치는 정확하게 모르고, 디스크 외부에서 로지컬 블럭을 보고 스케줄링을 하면 디스크 섹터 위치와 맞아 떨어지기 때문에 이런 식으로 해결한다. 내부에서 해결하는 방식은 잘 쓰지 않는다.
Q. 실린더 번호가 0~199번까지 존재한다고 할 때,
1. FCFS First Come First Service : 들어온 순서대로 처리
헤드의 이동거리가 길어지기 때문에 대단히 비효율적
2. SSTF Shortest Seek Time First
현재 헤드 위치에서 제일 가까운 (큐에 들어온)요청을 가장 먼저 처리한다.
53인 헤드에서 제일 가까운 요청은 65이기 때문에 가장 먼저 처리
65 다음은 67 -> 37 -> 14 ....
현재 헤드 위치에서 가까운 순서대로 처리하는 방식으로 이동거리가 줄어드는 것은 사실이나, starvation이 발생한다.
왜냐하면, 큐에 다시 헤드와 가까운 요청이 들어오면 영원히 처리되지 못하는 요청이 생기기 때문
3. SCAN 가장 획기적이고 간단한 방식, = 엘리베이터 스케줄링이라고 부름
큐에 들어온 요청과 상관없이 (상황에 좌우되지 않고) 가는 길목에 들어온 요청이 있으면 다 처리하는 방식
디스크 헤드의 이동거리도 짧아지고, starvation 문제도 발생하지 않아 비교적 공정하고 효율적
그러나, 실린더 위치에 따라 대기시간이 다른 문제가 있다.
-> 가장자리의 요청의 경우, 헤드가 떠나면 기다리는 시간이 엄청 오래 걸림
-> 가운데의 요청의 경우, 헤드가 떠나면 가장자리보단 덜 걸림
4. C-SCAN : Circular SCAN
한 쪽 끝에서 다른 쪽 끝으로 이동하며 길목 요청을 다 처리하고 다시 반대로 돌아갈 때는 요청을 처리하지 않는 것
헤드가 위치만 이동하는 것이라 이동 거리가 길어질 뿐, 대기시간은 균일하다.
이외에도 N-SCAN, LOOK, C-LOOK이 있다.
N-SCAN : 출발을 하면서 큐에 들어온 요청은 처리하고, 출발을 시작한 후에 큐에 들어온 요청들은 그 다음 재출발에 처리하겠다는 것
5. LOOK / C-LOOK
SCAN과 C-SCAN의 비효율적인 걸(끝까지 요청이 없음에도 0번과 199번 실린더까지 가는 것) 개선한 것
- SCAN을 쓰는데 끝까지 가는 도중에 더 이상 요청이 없으면 방향을 바꾸는 것 -> LOOK
- C-SCAN을 쓰는데 (이하 동일) -> C-LOOK
그 외
현대 디스크 시스템은 SCAN에 기반한 알고리즘을 쓰고 있다.
스케줄링은 파일의 할당 방법에 따라 디스크 스케줄링에 영향을 미친다.
연속할당, 산발적할당이냐에 따라 헤드의 이동이 달라지니까!
요청을 merge해서 한꺼번에 처리를 하는 것이 디스크 I/O의 효율성을 높이는 것
디스크 스케줄링 알고리즘을 필요에 따라 교체해서 쓸 수 있어야 한다!
'⭐️ Computer Science > 운영체제' 카테고리의 다른 글
[운영체제] 2. 메모리계층, 가상메모리, 스와핑, 페이지폴트, 스레싱 (0) | 2022.08.21 |
---|---|
[운영체제] 1. 운영체제와 컴퓨터, 인터럽트, 시스템콜과 modebit (0) | 2022.08.21 |
[운영체제] 28. Disk Management & Scheduling 2 (0) | 2022.08.14 |
[운영체제] 26. File System Implementations 2 (1) | 2022.08.10 |
[운영체제] 25. File System Implementations 1 (0) | 2022.08.07 |