전체 글 (117) 썸네일형 리스트형 파일 시스템 구현 파일 시스템은 순수한 소프트웨어다. 다른 가상화들과 다르게 하드웨어가 필요하지 않다. 파일 시스템을 구현하는 다양한 방법이 존재하기 때문에 파일 시스템들이 서로 다른 자료 구조를 갖고 있으며 각각은 장단점이 있다. 파일 시스템에 대해 학습할 때, 두 가지 측면에서 접근하는 게 좋다 그중 하나가 자료구조이고 다른 하나는 접근 방법이다. 파일 시스템이 자신의 데이터와 메타데이터를 관리하기 위해 어떤 종류의 자료구조가 있어야 하는가? 그리고 프로세스가 호출하는 시스템 콜들과 파일 시스템의 자료구조와 어떤 관련이 있는지 어떤 자료구조들이 읽히는지 등을 알아야 한다. 파일 시스템의 자려 구조에 대해 디스크 상의 전체적인 구성을 개발하기 위해서는 디스크를 블록으로 나눠야 한다. 여기서는 단일 블록을 사용하고 크기는.. RAID 질문으로 시작하겠다. 대용량이면서 빠르고 신뢰할 수 있는 디스크를 어떻게 만들까?? 그래서 나온 게 RAID다. Redundant Array of Inexpensive Disk라고 하는데, 간단히 말해서 여러 개의 디스크를 조화롭게 사용하여 고속이면서 대용량의 신뢰할 수 있는 디스크 시스템을 만든다. RAID는 하나의 디스크처럼 행동한다. 용량이 많아지고 신뢰성도 올라간다. 그 이유는 여러 디스크에 중복된 것을 쓸 수 있으니까. 또한 이러한 장점을 transparently 하게 제공한다. 즉 소프트웨어의 변경 없이 디스크를 RAID로 변경 가능하다. 이제 인터페이스와 결함 모델을 살펴보고, 그 후 용량과 신뢰성 그리고 성능을 살펴보자. 파일 시스템이 RAID에 논리적 I/O를 요청하면 RAID는 내부에서.. 하드 디스크 드라이브 파일 시스템 기술들이 거의 대부분 하드 디스크 드라이브의 동작에 기반을 두고 개발되었기 때문에 하드 디스크 드라이브에 대해 알아보자. 디스크에 있는 데이터를 어떻게 저장하고 접근할까?? 모든 현대 드라이브의 기본적인 인터페이스는 단순하다. 드라이브는 읽고 쓸 수 있는 매우 많은 수의 섹터(512byte)들로 이루어져 있다. 디스크 위의 n개의 섹터들은 0부터 n-1까지의 이름이 붙어 있다. 따라서 디스크를 섹터들의 배열로 볼 수 있고 0부터 n-1이 드라이브의 주소가 된다. 많은 파일 시스템들이 한 번에 4KB를 읽거나 쓴다. 하지만 드라이브 제조사는 하나의 512byte 쓰기만 원자적이라고 보장한다. 그래서 갑자기 전력이 나가면 대량의 쓰기 중에 일부만 완료될 수 있다. 이런 현상을 torn write.. 입/출력 장치 개념 I/O 장치 영속성 이야기 전에 입/출력 장치의 개념을 소개하고 운영체제가 이 장치들과 상호 작용하는 방법을 알아본다. 밑의 그림을 보면 CPU와 주메모리가 메모리 버스로 연결되어 있고, 몇 가지 장치들이 범용 I/O 버스에 연결이 되어 있다. 많은 현대 시스템에서는 PCI(많은 파생 버스)를 사용한다. 여기에 그래픽이나 다른 고성능 I/O 장치들이 연결되고 그 밑에 SCSI나 SATA 또는 USB 같은 주변장치용 버스가 있다. 여기서 디스크나 마우스 같은 느린 장치들이 연결된다, 가까울수록 고속화 버스를 사용하는데 여기에 고성능 장치들이 배치된다. 비용적인 문제 때문. 다음은 가상의 표준 장치를 살펴 보자 두 개의 중요한 요소가 있다. 첫 번째는 시스템의 다른 구성 요소에게 제공하는 하드웨어 인터페이스.. Threads 여기서는 몇 가지 기억에 남는 것들만 정리함. 먼저 대기하는 스레드가 조건을 검사할 때 if문 대신 while문을 사용하는데 이게 일반적으로 간단하고 안전하다. 예를 들어 pthread 라이브러리에서 변수를 제대로 갱신하지 않고 대기하던 스레드를 깨울 수 있다. 이런 경우 재검사를 하지 않는다면 대기하던 스레드는 조건이 변경되지 않더라도 변경되었다고 생각함. 때문에 컨디션 변수에서 시그널 도착은 변경 사실을 알리는 것이 아니라, 변경된 것 같으니 검사해 보라는 힌트 정도로 보는 것이 더 안전하다. 또한 컨디션 변수 사용하지 않고 간단하게 플래그 형식으로만 구현하면 굉장히 위험하다. 코드의 성능이 일단 좋지 않고, 오류 발생하기가 쉽다. lock 여러개의 명령어들을 원자적으로 실행해보고 싶지만 단일 프로세.. Pintos Project3: Virtual Memory 지금까지 만든 pintos project는 몇가지 한계가 있었다. 먼저 swap을 진행 할 수 없고 demand paging이 사용 불가 했고 가상 메모리가 구현 되지 않았다. 이번 프로젝트에는 이런 점들을 보완할 것이다. 그 전에 먼저 Supplemental page table을 정리하고 넘어가야 한다. 우리가 기존에 아는 페이지 테이블에 좀 더 보충해주는 역할을 하는 테이블이다. 각 페이지에 대한 추가 데이터로 페이지를 보완한다. 여기서는 페이지 테이블과 같게 봐도 될 것 같다. 페이지 폴트가 났을때 추가 되어야 할 데이터를 알 수 있고, 프로세스가 종료 되었을때 해제 되어야할 자원을 알 수 있게 해준다. 우리 프로젝트에서는 hash 를 사용해서 페이지들을 관리 한다. supplemental_page.. Pintos Project2: User Programs 아 일단 시간이 너무 없어서 프로젝트가 다 끝난 뒤 정리용으로 써야 될 거 같다. 먼저 저번 프로젝트에서 부팅이 된 후 커널 스레드를 생성시켜 프로세스를 돌게 만들고 우선순위 별로 스케줄링하는 단계까지 구현을 했다. 이번 프로젝트에서는 사용자 명령어를 받아서 시스템 콜들을 실행하는 단계를 구현해야 한다. 그래서 일단은 argument passing을 먼저 처리해야 한다. 우리가 쉘에서 명령어를 입력하면 그 명령어대로 처리할 수 있게 입력된 명령어들을 잘 파싱 하여서 스택에 올리고 실행할 수 있게 넘겨주는 것이다. 이 동작은 밑에 코드를 보면 알 수 있다. 이전 단계에서는 무시되었던 코드다. 우리가 입력한 명령어가 저 task 인자로 들어간다. 이곳으로 들어오면 우리가 입력한 명령어에서 실행해야 될 커맨드.. Virtual Memory 주소 변환의 원리 cpu와 마찬가지로 memory에서도 가상화 비슷한 전략을 추구한다. 제어와 효율성을 추구함. 프로그램을 다른 프로그램으로부터 보호하고 운영체제를 프로그램으로부터 보호하려면 하드웨어 도움이 필요함. 밑의 핵심문제를 보자 여기서 다루는 기법은 하드웨어-기반 주소 변환인데 짧게 주소 변환이라고도 한다. 가상 주소를 물리 주소로 변환하는 것. 주소 변환은 하드웨어가 하지만 하드웨어를 셋업 하기 위해 운영체제가 관여해야 함. 메모리의 빈 공간 사용 공간 등 알고 있어야 함. 먼저 가장 간단한 가정부터 시작함 사용자의 주소 공간이 물리 메모리에 연속적으로 배치되어야 한다고 가정. 또한 주소 공간은 물리 메모리 크기보다 작고, 주소 공간의 크기가 같다고 가정. 예시를 보면 프로그램 관점에서 0부터.. 이전 1 ··· 7 8 9 10 11 12 13 ··· 15 다음