- 데이터 기록 판독원리
- 플래터 : 디스크
- 헤드 : 서버 모터에서 움직임
- 자석 : 플래터의 원하는 위치를 자화 시켜서 0 또는 1의 데이터를 읽음 -> 자기장을 이용
- 헤드와 플래터 사이는 떨어져 있음 ->담배연기입자보다 더 얇은 간격, 지문 자국의 두께보다 얇음
- 스크레치가 나면 플래터의 한 부분을 쓰지 못하게 됨
- 헤드가 동작중 움직이면 안되므로 단단히 고정되어 있음 -> 플래터 역시 흔들리지 않도록 고정 -> 만약 인위적으로 흔든다면 수명이 짧아짐
- Moving-Head Disk Mechanism
- 플래터가 여러겹으로 되어있는 경우도 있음
- 요즘에는 하나의 플래터에 사용하는 경우도 있음
- 플래터가 회전할 때, 헤더 크기만큼 반지름이 같은 구역이 생기는데 이를 track이라고 함
- 그 트랙을 일정한 크기로 잘라놓은 영역을 sector라고 함 -> 하드디스크는 한번에 섹터의 데이터 하나를 읽음
- cylinder : 여러개의 디스크 중 트랙(반지름)이 같은 부분(겹치는 모든 디스크의 트랙들)
- spindle : 모터에 연결되어 디스크들의 가운데에 나와있는 기둥
- rotation : 디스크를 회전시키는 것
- arm : 헤드가 붙어있는 부분
- arm assembly : 암 전체를 동시에 움직이는 것
- 암 어셈블리가 원하는 트랙에 헤드를 위치시키는 시간과 원하는 데이터가 있는 섹터가 올 때까지 기다리는 시간만큼의 지연이 있음
- 암이 움직이는 시간 + 섹터가 돌아오는 시간 = 지연시간
- 위에서 본 모양
- 이 디스크는 3개의 플레터에 양면의 헤드(6개)가 있음
- 같은 트랙을 가지는 3개의 디스크의 부분을 실린더라고 함
- 섹터는 매우 작음, 하나 씩 읽을 수도 있지만 효율성이 떨어지기 때문에 보통 여러개를 묶어서 데이터의 기본단위로 사용 -> 클러스터
- 클러스터 : 여러 개의 섹터를 묶은 것(최소 데이터), 논리적 크기 -> 클러스터를 너무 많이 설정해 놓으면 빈 공간이 많이 생길 수 있음
- 인터리브
- 너무 빨리 돌아가면 데이터를 읽고 버퍼를 비우는 동안 다음 데이터가 올 수 있음
- 이러한 경우에는 버퍼가 비워지는 동안 그 데이터를 읽지 않고 한 번 보내서 딜레이가 생김 -> 효율이 안좋아짐
- 메모리 크기, 전송속도 등을 고려하여 순서를 섞어서 사이사이에 기다리는 텀을 주도록 함
- 연속으로 붙어있는 방식은 1:1, 한 칸씩 떨어진 경우 1:2 방식이라고 부름
- Storage Hierarchy : speed(속도), Cost(비용), Volatility(휘발성)
- magnetic tapes : 현재는 잘 사용하지 않지만 가격대비 보존기간이 가장 길다. 안정적
- optical disk : CD, DVD 등
- magnetic disk : Hard disk
- electronic disk : SSD
- main memory : RAM
- cache
- register : CPU안에 있는 저장장치
- 위로 갈수록 휘발성이 높고 용량당 가격이 비싸짐, 속도가 빨라짐
- 컴퓨터 시스템 구상에 맞게 잘 사용해야 함
- System Call
- 시스템 콜 : 운영체제가 제공하는 서비스 프로그램(C언어나 어셈블리어로 개발)
- 고급언어에서는 시스템 콜이 불편하거나 힘들 수 있음 -> 이를 위해 고급언어로 함수를 사용할 수 있도록 만들어 놓은 것이 API라고 함
- ex) windows : win32 API, POSIX API : UNIX, Linux, Max OS X 등 POSIX based systems, Java API : Java virtual machine(JVM)
- system call들의 예
- 원본 파일을 단순히 복사하여 다른 곳에 붙여넣을 경우 사용되는 시스템 콜들
- 우리는 복사, 붙여넣기로 끝
- 표준 API(시스템 콜을 쓸 수 있도록 잘 만들어 놓은 것)의 예
- man 명령어로 시스템 콜들을 검색하여 사용방식을 알아낼 수 있음
- 자주 사용하는 시스템 콜들은 사용법을 외워놓는 것이 좋고 가끔 사용하는 것들은 검색해서 사용할 것
- System Call Implementation
- System Call 10H function 2 (sub function 2) : 시스템 콜들은 여러가지가 있어서 구분 해놓는 것
- OS커널 내에 해당하는 것을 호출
- 시스템 콜은 내부에서 호출, 인터럽트는 외부
- 호출하는 쪽은 어떻게 구현되어 있는지 알 필요는 없고 어떻게 사용하는지만 알고 있으면 된다. -> 하드웨어 제어는 운영체제가 하는 역할이므로 사용자는 할 필요 없음
- API의 상관관계 : API, system call, 운영체제
- 프로그램에서 동작을 넣음
- 표준함수(API)가 시스템 콜을 호출
- 다시 돌아감
- 미리 구성되어 있는 시스템 콜을 동작시키는 경우에는 유저모드가 아니라 커널모드에서 동작한 후 돌아온다.
- System Call Parameter Passing
- 시스템 콜도 하나의 함수처럼 동작하므로 전달인자가 있을 수 있음
- CPU안의 register를 직접 이용하는 방식 : 데이터를 넣고 사용
- 임의의 메모리에 테이블과 같은 형태로 데이터를 저장하고 위치를 전달
- 스택에 데이터를 집어넣은 후 몇 개가 저장되어있는지 알려주면 마지막부터 데이터를 가져감
- 가장 빠른것은 레지스터를 이용하는 방식
- System Call의 타입
- 프로세스의 제어(process control) : (프로세스란 저장되어있는 상태인 프로그램에 메인메모리에 올라와서 실행될 수 있는 상태) 프로그램을 로드하여 메모리에 올리고 프로세스로 등록을 하고 실행을 기다림
- Single Tasking(MS-DOS) : 한 번에 하나의 프로세스만 처리하는 간단한 운영체제라면 빈 공간에 하나씩 불러와서 처리
- FreeBSD(Multi Tasking) : 여러개의 프로세스를 메모리에 올릴 수 있다면 적절히 빈 공간에 프로세스들을 분배, 기다릴 때 사용자가 요청하는 프로세스를 fork()함수로 자식 프로세스를 만들어서 실행
- 파일 관리(File management) : 파일을 만들고 복사 등의 일을 함
- 장치 관리(Device management) : 컴퓨터 시스템에 붙어있는 외부 장치들을 어떻게 관리 할것인지 시스템콜로 구성 -> 표준화하여 여러 곳에서 동일하게 사용(운영체제가 표준을 가지고 있으면 하드웨어가 거기에 맞춰서 출시됨)
- 정보 유지(Information maintenance) : 시간과 날짜 등등의 정보를 다룸
- 통신(Communication) : 프로세스(한 컴퓨터 내일수도 다른 컴퓨터일수도)간의 통신
- Protection : 하드웨어 또는 리소스를 보호, 하드웨어의 추상화
- 시스템 호출의 유형
- windows는 함수의 이름이 길지만 알아보기 쉽게 문장으로 되어있고 Unix는 약자로 되어있음
- System Services
- 운영체제에 딸려있는 여러가지 외부 실행프로그램으로 존재하는 시스템프로그램으로써의 서비스
- 중요한 시스템콜을 이용한 간단한 유틸리티들의 집합 -> 각각의 시스템콜을 프로그램처럼 사용할 수 있도록 만들어 놓음
- 간단하고 작은 일들은 미리 만들어서 제공함
- 운영체제에서 제공되는 실행파일이 모두 서비스 프로그램은 아니다. 운영체제와 관계없는 것들도 제공됨 - ex)계산기, 게임 등
- Why Applications are Operating System Specific
- 어플리케이션은 운영체제들마다 따로 만들어진다. -> 형태, 포멧 등의 이유가 있겠지만 운영체제마다 시스템 콜이 다르기 때문
- 운영체제가 쓰는 서비스를 달리 써야함
- 인터프리터에서 동작하는 소스(파이썬, 매트랩 등)는 운영체제가 달라도 인터프리터 위에서 돌아가므로 소스레벨에서 호환성을 가짐, 바이너리 레벨에서는 호환성을 가질 수 없음
- 운영체제의 구조
- 우리가 사용하는 운영체제는 규모가 상당히 큰 편
- 용도와 목적에 따라서 운영체제에 필요한 구조가 달라질 수 있음
- 단순한 구조(simple structure)
- 최소의 공간에 최소의 방법으로 최대의 기능
- 마이크로소프트의 초창기 DOS(MS - DOS)가 IBM에서 표준 OS로 채택하고 부터 발전 : DOS는 여러개의 모듈로 나누어져 있지 않고 운영체제 자체가 통째로 동작하는 형태
- 제일 아래 ROM BIOS(basic input output system)가 동작 : 기본적인 입출력하는 기능을 하드웨어에 내장
- 그 위에 MS-DOS라는 운영체제를 올림 : 하드웨어가 필요하다면 추가의 드라이버가 포함되어 있을 수 있음
- resident program(상주 시스템 프로그램)은 있을 수도 있고 없을 수도 있음
- 어플리케이션 동작
- 어플리케이션이 하드웨어를 직접 사용할 수 있음
- 운영체제의 시스템 콜과 하드웨어의 시스템 콜이 따로 있음
- Linux System의 구조 : monolithic(한 덩어리) plus modular(개별 단위) design 둘 다 가능
- 계층적 접근(Layered Approach)
- layer 0은 하드웨어 N은 유저 인터페이스 -> 이렇게 레이어를 나누고 어떤 것이 들어갈지 넣어줌
- 네트워크 처럼 단순하게 주고받는 것이 아니라서 레이어를 나누는 것은 아주 어려운 일
- 개념과 접근방식은 좋음 -> 인기는 없음
- 마이크로 커널(Microkernels)
- 커널이 가져야할 핵심적인 기능은 최소로 만들고 나머지 서비스들을 프로세스로 만들어 항상 상주하도록 함
- 카네기 멜론 대학에서 마이크로 커널을 기반으로 Mac OS X가 시작됨
- 다루기가 쉽고 커널이 작아서 오류가 적고 안정적 그러나 커널이 하는 일이 없어져서 유저와 커널모드가 주고 받는 경우가 빈번해짐 -> 효율이 떨어질 수 있음
- 커널 최소화, 서비스 기능이 만들어져 있음
- 마이크로커널에서 서비스들이 통신
- 마이크로 커널 시스템 스트럭쳐라고 함
- 모듈(Modules)
- 만들어진 여러가지 형태의 모듈로 나눠서 필요한 것만 조립식으로 탑재
- 커널 주위에 모듈이 장착
- 새로운 것이 만들어지면 기존의 것을 빼고 교체하면 됨
- 전체를 빌드하기도 하고 모듈에 따라 부분적으로 빌드할 수도 있음
- 혼용 시스템(Hybrid Systems)
- 현대에서는 위의 방식들을 적절하게 혼용하여 더욱 나은 모델로 발전시킴
- 하나의 방법에 얶메어있지 않다.
- Building and Booting an Operating System
- 여러가지 목적과 형태로 된 소스들을 모듈화 분산화하여 나누어놓고 내가 필요한 것을 묶어서 운영체제를 만들기도 한다.
- 각각의 모듈들을 install한 후 또 install하여 전체가 하나로 돌아가면 우리가 알고 있는 운영체제가 된다.
- 리눅스 소스 코드 : http://www.kernel.org
- System Boot
- 부팅 : 운영체제가 처음부터 작동하는 과정
- 초기의 작은 부트로더가 저장되어있는 운영체제 이미지를 메모리로 불러와서 탑재시키고 하드웨어를 초기화하면서 작동
- 커널을 로드한 후 커널의 첫 번째 시작부분부터 시작
- 유저가 원하는 기능을 입력받아서 작동
- Operating - System Debugging
- 디버깅 : 오류를 찾아 수정, 매 순간마다 로그를 남김
- core dump : 문제가 되는 순간의 중요한 값을 저장시킴, 스마트폰 같은 경우는 시간축이 필요하므로 덤프가 어려워서 별도의 툴을 사용하기도함
- 덤프 순간의 정보에는 CPU의 모든 정보, 프로그램의 어느 위치인지 등등이 있음
- 이 정보를 가지고 역추적을 하면 시스템 커널에서 어떤 시스템의 어떤 소스에서 몇 번째 줄이 어떤 변수의 값을 가지고 CPU의 어떤 컨텍스트일때 문제가 있었는지를 알 수 있음
- 커널의 문제인지 어플리케이션의 문제인지 단순히 하드웨어의 문제인지 가려낼 수 있음
- 문제가 생길경우 덤프파일을 저장한 후 재부팅을 시작
'운영체제' 카테고리의 다른 글
| Chapter 5 - CPU Scheduling (0) | 2019.04.09 |
|---|---|
| Chapter 4 - Threads(6주차) (0) | 2019.04.09 |
| Chapter 2 - 시스템 구조 (0) | 2019.03.14 |
| Chapter 1 - 운영체제의 구조, 운영체제 연산, 프로세스와 메모리 관리 (0) | 2019.03.09 |
| Chapter 1 - 운영체제가 하는일, 컴퓨터 시스템의 구성, 컴퓨터 시스템 구조 (0) | 2019.03.09 |
