[문과 코린이의 IT 기록장] 운영체제(OS) - File Systems & File System Implementations ( File and File System, Directory and Logical Disk, Open() 연산, File Protection, File System의 Mounting, Access Method, Allocation of File Data in Disk, 파일 시스템 구조, Free-Space Management, Directory Implementatation, VFS and NFS, Page Cache and Buffer Cache, 프로그램의 실행)
운영체제
운영체제는 컴퓨터 하드웨어 바로 위에 설치되는 소프트웨어 계층으로서 모든 컴퓨터 시스템의 필수적인 부분이다. 본 강좌에서는 이와 같은 운영체제의 개념과 역할, 운영체제를 구성하는 각
www.kocw.net
[문과 코린이의 IT 기록장] 운영체제(OS) - Virtual Memory (Deamand Paging, Page Fault 처리 루틴, Replacement Algo
[문과 코린이의 IT 기록장] 운영체제(OS) - Virtual Memory (Deamand Paging, Page Fault 처리 루틴, Replacement Algorithm, Page Frame의 Allocation, Global vs Local Replacement, Tr..
vansoft1215.tistory.com
1. File and File System
* file : HDD에 저장하는 단위
* file system : 이름을 통해 접근하는 장치
* memory system : 주소를 통해 접근하는 장치
1) File
- 관련 정보를 이름을 가지고 저장하는 것
- 일반적으로 비휘발성의 보조기억장치(ex.HDD)에 저장함
- 운영체제는 다양한 저장 장치를 file이라는 동일한 논리적 단위로 볼 수 있게 해줌.
* file은 데이터를 저장하는 목적으로만 쓰는 것이 아니라, os에서는 여러가지 장치들을 관리하기 위해서 file을 사용
* HDD1, HDD2 등이 존재하면, 운영체제는 이 장치들을 서로 다른 파일로 관리하곤 함.
* 이를 dveice special file이라고 함. (일반적인 접근 파일과는 다름)
- 파일에 의해 정의되는 연산
: create -파일 생성
: read, write - 파일 읽기, 파일 쓰기
: reposition(iseeek) - 파일의 현재 접근 위치를 수정해주는 역할
* 일반적으로 파일을 한번 읽게 되면, 위치를 가리키는 파일의 포인터가 그 다음 위치로 자동 이동하게 됨. 이 위치를 수정해주고 싶을 때 사용하는 것이 reposition
: delete - 파일 제거
: open , close - 파일 열기, 파일 닫기
* open의 역할 : 파일내용을 디스크에서 바로 메모리로 올리는 것이 아니라, opne을 통해 파일의 metadata를 메모리로 올리는 역할을 하기 때문
2) File attribute (혹은 파일의 metadata)
- 파일 자체의 내용이 아니라, 파일을 관리하기 위한 각종 정보들
ex. 음악 파일
metadata: 파일 이름, 유형, 저장된 위치, 파일 사이즈, 접근권한(읽기/쓰기/실행), 시간(생성/변경/사용), 소유자 등
파일 내용 : 음악
3) File System
- 운영체제에서 파일을 관리하는 소프트웨어 부분
- 파일 내용 및 파일의 metadata, 디렉토리 정보 등을 관리함.
* 일반적으로 파일 시스템을 저장할 때 1차원적으로 저장하지 않음
* 디렉토리를 둬서, 계층적으로 저장을 함.
* 대부분의 파일 시스템이 관리상 편의성을 위해, 디렉토리를 제공하고 있음.
- 파일의 저장 방법 결정 및 파일의 보호 등을 담당함
2. Directory and Logical Disk
1) Directory란?
- 파일의 metadata 중 일부를 보관하고 있는, 일종의 특별한 파일
* directory도 하나의 파일임
* directory에다가 metadata를 모두 저장할 수도 있지만, 일반적으로 일부 metadata는 directory에 직접 저장하고, 나머지는 다른 곳에 저장하기도 함.
- directory에 대해 정의되는 연산
: search for a file - directory 밑에 존재하는 파일을 찾는 것
: create a file - directory 밑에 존재하는 파일을 만드는 것
: delete a file - directory 밑에 존재하는 파일을 지우는 것
: list a dirrectory
: rename a file - directory 밑에 존재하는 파일의 이름을 변경하는 것
: traverse the file system
2) Partition (= Logical Disk)
* disk의 종류 - 물리적인 disk vs 논리적인 disk(Partition)
* 운영체제가 보는 disk는 논리적인 disk(Partition)임
- 하나의 (물리적) 디스크 안에 여러 파티션을 두는 것이 일반적임
- 여러 개의 물리적인 디스크를 하나의 파티션으로 구성하기도 함.
ex. HDD를 하나 사서, C드라이브 / D드라이브 등으로 나누는 것 (C, D드라이브가 각각 파티션임)
- (물리적)디스크를 파티션으로 구성한 뒤, 각각의 파티션에 file system을 깔거나 swapping 등 다른 용도로 사용할 수 있음.
3. Open() 연산
# open()연산 : 파일의 metadata를 메모리로 올려놓는 것
ex. open("/a/b/c")
- 디스크로부터 파일 c의 metadata를 메모리로 가지고 옴 (즉, 이 뜻은 파일 c를 찾아오라는 것)
- 이를 위하여 directory path를 search함
1) 루트 디렉토리 '/'를 open한 후, 그 안에서 파일 'a'의 위치 획득 (루트 디렉토리의 위치는 미리 알려져있음)
2) 파일 'a'를 open한 후, 그 안에서 파일 'b'의 위치 획득
3) 파일 'b'를 open한 후, 그 안에서 파일 'c'의 위치 획득
4) 파일 'c'를 open한다
- directory path의 search에 너무 많은 시간이 소요됨
: 따라서 open을 read/write와 별도로 두는 이유가 이 때문임.
: 한번 open한 파일은 read/write시 directory search 불필요함
- Buffer cashing
: 파일 content의 내용을 프로세스에게 전달해주기 전에, 운영체제가 자신의 일부 메모리 영역에 copy해놓고 전달해줌. 만약, 이 프로그램 혹은 다른 프로그램이, 동일한 파일의 동일한 위치를 요청하게 된다면 (즉, read system call을 한다면), 운영체제는 바로 이 내용을 복사해서 전달해줌
* paging기법에 대해 이야기할 때는, 이미 메모리에 올라와있는 페이지에 대해 운영체제가 개입하지 못하여, 주소변환을 하드웨어가 진행했었음. page fault가 날 때만, os에게 cpu제어권이 넘어옴
* 그러나 file system에서의 buffer cashing은 요청한 내용이 buffer cashing 안에 있던 없던, 일단 운영체제에게 cpu제어권이 넘어옴. 즉, 항상 cpu제어권이 os에게 넘어옴
: 따라서, buffer cashing 환경에서는 LRU알고리즘 / LFU알고리즘을 활용할 수 있음. (운영체제가 모든 환경을 다 인지하고 있기 때문에)
- File descriptor (file handle, file control block)
= File descriptor table ( = per-process file descriptor table)
: Open file table에 대한 프로세스별 위치정보
- Open file table (= system-wide open file table)
: 현재 open된 파일들의 metadata 보관소. 메모리 안에 있음
: 디스크의 metadata보다 몇 가지 정보가 더 추가됨
a. Open한 프로세스의 수
b. File offset : 파일 어느 위치 접근 중인지 표시 (별도의 테이블 필요)
* 즉, 이 테이블이 운영체제 구현에 따라 전역적으로 1개만 있을수도, 2~3개 있을수도 있음
ex. 프로세스가 어딜에 접근중인지 offset을 관리하는 file offset table, 프로세스와 무관하게 가지고 있는 open file table
4. File Protection
* 파일 보호, 파일의 접근권한과 관련한 이야기
- 각 파일에 대해 누구에게 어떤 유형의 접근(read/write/execution)을 허락할 것인가?
* 메모리 보호는 read/write권한에 대해서만 이야기함 (메모리는 프로세스마다 별도로 가지고 있기 때문)
* 파일에 대한 보호는, 여러 사용자/프로그램이 함께 사용가능하기 때문에, 접근권한중에 execution(접근연산) 가능 부분도 고려해야 한다.
[ File Protection과 관련해서, 권한을 제어하는 3가지 방법 ]
1) Access Control Matrix
- 행열에 사용자와 파일 이름들을 나열해 놓고, 각각의 사용자가 각각의 파일에 대해 어떤 권한이 있는지에 대해 표시해놓는 것.
- 이 방법은 특정 사용자가 본인만 사용하려고 만들어놓은 파일이 있는 경우, 즉 다른 사용자들에 대한 접근권한이 전혀 없을 경우에, 상당히 큰 공간 낭비를 초래함.
- 따라서, linked list 형태로 만드는 것이 효율적일 것이며, 그 방법은 두 가지가 있음
a. ACL : 파일별로 누구에게 접근 권한이 있는지 표시
b. Capability : 사용자별로 자신이 접근 권한을 가진 파일 및 해당 권한 표시
- 그러나 이런 방법을 사용해도 오버헤드가 상당히 큼.
2) Grouping
# 일반적인 os에서는, 이 방법을 사용해서 접근권한을 제어하고 있음
- 전체 User를 owner, group, public의 세 그룹으로 구분
- 각 파일에 대해 세 그룹의 권한 (rwx)를 3bit씩 표시
ex. UNIX
| owner | group | public | ||||||
| r | w | x | r | - | - | r | - | - |
* 이 방법을 사용하게 되면, 파일 하나에 대해 접근권한을 나타내기 위해 총 9bit만 있으면 됨
3) Password
- 파일마다 password를 두는 방법 (directory 파일에 두는 방법도 가능)
- 모든 접근 권한에 대해 하나의 password : 보안적으로 안전하지 못함.
- 접근권한별 password : 암기 문제, 관리 문제 발생 가능
5. File System의 Mounting
- 하나의 Physical Disk(물리적 디스크)를 파티셔닝을 통해, 여러개의 Logical Disk(논리적 디스크)로 나눌 수 있다고 함
- 각각의 Logical Disk(논리적 디스크)에는 file system을 설치해서 사용할 수 있음
- 만약 다른 파티션에 설치되어 있는 file system을 접근해야한다면 어떻게 해야하는가?
=> 이를 제공하기 위한 방법으로 Mounting이라는 연산이 있음
6. Access Method
- 시스템이 제공하는 파일 정보의 접근 방식
1) 순차 접근 (sequential access)
- 카세트 테이프를 사용하는 방식처럼 접근
ex. c를 보고 싶다면 : a->b->c 접근 가능
- 읽거나 쓰면 offset은 자동적으로 증가
2) 직접 접근 (direct access, random access)
- LP 레코드 판과 같이 접근하도록 함 (레코드판, CD, HDD 등)
- 파일을 구성하는 레코드를 임의의 순서로 접근할 수 있음
ex. c를 보고 싶다면 : a->c접근 가능 (특정 위치를 접근한 다음 원하는 위치를 접근하는 것이 바로 가능)
# 아무리 직접접근이 가능한 매체라도, 관리를 어떻게 하느냐에 따라 순차접근만 가능하도록 하는 경우도 있음
7. Allocation of File Data in Disk
- Disk에 파일의 데이터를 저장하는 3가지 방법
* Disk 내부에 파일을 저장할 때는, 동일한 크기의 sector 단위로 데이터를 저장하고 있음.
* 즉 어떤 임의의 크기를 지닌 파일을, 동일 크기의 블록 단위로 나눠서 저장하고 있음 (메모리 관리의 paging기법과 비슷)
1) Contiguous Allocation (연속할당 방법)
- 하나의 파일이 디스크 상에 연속해서 저장되는 방법
ex. directory파일 내에 5개의 파일(count, tr, mail, list, t)의 metadata를 담고 있음. 그 길이가 위와 같다는 것
[ 장점 ]
- Fast I/O 가능
: 한번의 seek/rotation으로 많은 바이트 transfer
* 어떤 파일을 통째로 읽고 싶을때, 한 번 seek(디스크 헤드 이동)를 통해 많은 양의 데이터를 한번에 받아올 수 있음
: Realtime file용으로, 또는 이미 실행중이던 프로세스의 swapping용
- Directed access(=random access) 가능
ex. 23번을 보고 싶을 경우 (19번 접근 + 4 -> 23번 접근 가능)
[ 단점 ]
- external fragmentation(외부조각) 발생 가능
* 파일의 크기가 균일하지 않기 때문에, 비어있는 블록이 연속 2개밖에 없는데, 내가 가진 파일은 3개가 필요하다면, 비어있는 공간임에도 불구하고 활용되지 못할 것임
- File grow가 어려움
: file 생성시 얼마나 큰 hole을 배당할 것인가?
: grow 가능 vs 낭비 (internal fragmentataion)
* 파일이 어느정도 커질 것을 대비해서 빈 공간을 미리 확보해놓을 수 있지만(외부조각 방지를 위해), 이는 내부조각이 발생할 수 있다는 문제 존재.
2) Liked Allocation (링크를 둔 연결할당방법)
- 파일의 데이터를 disk에 연속적으로 배치하는 것이 아닌, 빈 위치면 어디든 들어갈 수 있게 배치하는 것
- 즉, 어떤 파일의 시작위치만 directory가 가지고 있고, 그 다음 위치들은 그 위치에 직접 가서 파악하는 것 (마지막 위치에는 -1이 담겨있음)
[ 장점 ]
- External fragmentataion(외부 조각) 발생 안함
[ 단점 ]
- random access 불가능
* 원하는 위치를 보기 위해, 앞 부분을 모두 탐색해야 한다. (순차접근만 가능)
- Reliability 문제
: 한 sector가 고장나 pointer가 유실되면 많은 부분을 잃음
- Pointer를 위한 공간이 block의 일부가 되어 공간 효율성을 떨어뜨림 (이론적인 문제)
* 512 bytes / sector 중에 4 bytes / pointer 로 사용함 (비효율성 발생)
[ 변형 ]
- File-allocation table(FAT) 파일 시스템
* 포인터를 별도의 위치에 보관하여 reliability와 공간효율성 문제 해결
3) Indexed Allocation
- directory가 가지고 있는 블록이 idnex block이며, 이것을 통해 파일들이 어디어디 저장되어있는지를 열거해놓는 방식
[ 장점 ]
- External fragmentataion(외부 조각)이 발생하지 않음
- Direct access가능
[ 단점 ]
- small file의 경우 공간 낭비
* 아무리 작은 파일이라 하더라도 블록이 2개(index+데이터 저장) 필요함
* 파일크기의 분포를 조사해보면, 굉장히 작은 파일들이 많음. 따라서 공간낭비문제 심각
- Too Large file의 경우 하나의 block으로 index를 저장하기에 부족
* 굉장히 큰 파일의 경우에, 하나의 index 블록으로 그 파일의 블록 위치들을 다 표현할 수 없음.
| # 해결 방안 a. linked scheme - index블록의 실제 파일 위치가 어디인지를 쭉 찾아가다가, 파일의 크기를 다 커버 못한다면, 또 다른 인덱스 블록을 가리키게 함 b. multi-level index - 하나의 index블록이 직접 파일의 위치를 가리키는 것이 아닌, 또 다른 인덱스를 가리키도록 해서 2단계 page table을 사용하도록 함. 그러나 이 방법은 index를 통한 공간낭비가 심함 |
8. 파일 시스템 구조
1) UNIX 파일시스템의 구조
- 가장 기본적인 Unix 파일 시스템의 구조
* UNIX의 파일 시스템은 저장되는 구조가 크게 4가지로 구성됨
(1) Boot block
- 부팅에 필요한 정보 (boostrap loader)
* 컴퓨터 전원을 켜면 부팅을 하게 되는데, 그 때 메모리에 올릴 데이터의 기본 정보들
* 이 파일 시스템에서 운영체제 커널의 위치가 어딘지를 찾아, 그것을 메모리에 올려 정상적인 부팅이 이루어지도록 하는 것이 이 boot block의 역할
- 어떤 파일 시스템이던 가장 앞에 나오기로 약속되어 있음.
(2) Super block
- 파일 시스템에 관한 총체적인 정보를 담고 있다.
* 어디가 빈 블록이고, 어디가 실제 파일이 사용중인 블록인지 등을 관리함
* 또한 어디까지가 incode list이고, 어디부터 실제 data block이 있는지를 총체적으로 관리해줌
(3) Incode list
- 파일 이름을 제외한 파일의 모든 metadata를 저장
* 실제 파일 시스템을 구현할 때, directory가 metadata를 모두 가지고 있는 것이 아니라, directory는 파일의 이름과 incode 번호만 가지고 있고 나머지는 incode list가 별도로 빼서 보관하고 있음
* 파일 하나당 incode가 하나씩 할당됨
cf ) 파일의 위치정보는 어떻게 저장하는가?
- direct index : 파일 크기가 작으면 이것만 가지고 파일의 위치를 표시할 수 있음.
- single indirect (pointer) : direct index보다 큰 파일의 경우, 이로써 표현
- double indirect (pointer) : single indirect보다 큰 파일의 경우, 이로써 표현
* indirect의 경우 이를 따라가면 index 블록이 있고, 그 블록에 포인터가 여러개 들어가있는데, 그 포인터는 실제 파일의 위치를 가리키는 포인터임.
* 더 큰 것이 필요하다면 triple indirect (pointer)를 사용
# 이 방법이 효율적인 이유 : 대부분의 파일은 보통 크기가 작기 때문. 작은 파일들은 한번의 포인터 접근으로, 즉 incode만 메모리에 올려놓으면 파일의 위치를 바로 파악할 수 있음. 가끔 나타나는 큰 블록의 경우, 추가적인 방법을 통해 파일을 찾으면 더 효율적임.
(4) Data block
- 파일의 실제 내용을 보관
2) FAT 파일 시스템의 구조
* MS사가 MS DOS를 만들었을 때, 만들어진 파일 시스템
* 최근에도 windows 계열에서는 이 파일시스템을 활용하는 경우가 많음. 모바일 기기에서도 마찬가지.
(1) FAT
- FAT 파일 시스템에서는, 파일의 metadata 중 일부를 FAT이라는 곳에 저장하고 있음.
- 이 곳에는 metadata중 위치정보만 저장되고 있음. (나머지 metadata는 directory가 보유하고 있음.)
- FAT 배열의 크기는, Disk가 관리하는 Data block의 개수만큼 존재함.
- Data block의 첫 블록을 처리 한 후, 다음 블록을 찾기 위해 FAT의 entry로 감.
[ 장점 ]
a. 이 파일 시스템을 사용함으로써, linked allocation의 문제를 모두 해결하고 있음
: 포인터 하나가 bad sector가 되더라도, fat에 해당 위치정보가 담겨있기 때문에, 이후 오류를 바로잡을 수 있음
* 일반적으로 FAT은 Disk에 2개 이사 확보하고 있으므로, 유실될 가능성이 더 낮음.
: 512byte sector를 모두 사용 가능
b. FAT 파일 시스템은 직접접근이 가능하다는 장점을 지님
9. Free-Space Management
* 파일에 할당된 데이터들을 어떻게 관리하는가만 설명하고, 비어있는 블록들은 어떻게 관리한 것인지를 설명하지 않음
* 빈 공간을 관리하는 방법은 크게 4가지가 있음
1) Bit map or bit vector
| 0 | 1 | 2 | ... | n-1 |
| 1 | 0 | 1 | ... |
* bit 0 : block[i] 비어져있음
* bit 1 : block[i] 할당되어있음
- 단점 : Bit map은 부가적인 공간을 필요로 한다는 단점이 있음. 그러나 그렇게 많은 공간을 필요로 하지는 않음.
- 장점 : 연속적인 n개의 공간을 찾는데 효과적임.
2) Linked list
- 모든 free block들을 링크로 연결
- 단점 : 연속적인 가용공간을 찾는것은 쉽지 않음.
- 장점 : 공간의 낭비가 없다, 실제로 활용하기는 쉽지 않다.
3) Grouping
- Linked list 방법의 변형
- 첫번째 free block이 n개의 포인터를 가짐
: n-1포인터는 free data block을 가리킴
: 마지막 pointer가 가리키는 block은 또 다시 n pointer를 가짐
* 즉, 0번째 위치가 index 역할을 해서 빈 블록들을 포인터 형식으로 저장하고, 마지막번째인 n-1번째로 가면 또 새로운 블록들이 있다면 저장되있는 형식으로 이루어짐.
- 단점 : 연속적인 빈 블록을 찾기에는 효과적이지 않음
4) Counting
- 프로그램들이 종종 여러개의 연속적인 block을 할당하고 반납한다는 성질에 착안
- (first free block, # of contiguous free blocks)을 유지
- 장점 : 연속적인 블록 찾기에 효과적인 방법
* 즉, 연속적인 빈 블록을 표시하기 위해, 빈 블록의 첫번째 위치부터 몇 개까지가 빈 블록인지를 쌍으로 관리함.
10. Directory Implementatation
* directory 구현 방법 (어떻게 파일의 내용들을 저장하는가?)
* directory는 밑 파일들의 metadata를 관리하는 특수한 파일임
1) Liner list
*<file name, file의 metadata>의 list
- 단순하게 파일의 이름하고 그 파일의 metadata들을 순차적으로 저장하는 방법. 즉, 구현이 간단함.
* metadata의 크기는 가변적이지 않고 고정되어있음
- 디렉토리 내에 파일이 있는지를 찾기 위해서는, linear search 필요
* 디렉토리에 대한 연산이 주어졌을 때 (파일 찾기), 구성이 체계적으로 이루어져 있으므로 순차적으로 찾기가 쉽다.
* 구현은 간단하지만, 연산에 대해 시간이 많이 필요함 (time-conosuing)
| File name | File의 metadata |
| aaa | aaa의 metadata |
| cccc | cccc의 metadata |
| bbba | bbba의 metadata |
| ... | ... |
2) Hash Table
- liner list + hashing
* 파일의 이름을 그냥 저장하는 것이 아닌, hash함수를 적용해서 저장하는 것
- Hash table은 file name을 이 파일의 linear list의 위치로 바꾸어줌
* 어떤 input값이 주어지더라도, hash 함수의 결과값이 특정 범위의 숫자로 한정됨. (1<=f<=n 나오도록 적용)
* hash함수의 결과값이 나오는 entry에 값을 저장함
- search time을 없앰
* directory 밑의 파일을 찾는 연산을 수행할 때, 순차적 탐색이 아니라, hash함수를 적용한 후 바로 그 결과값 entry에 가서 확인할 수 있음. 효율적으로 사용 가능.
- Collision 발생 가능
* Collision : 서로 다른 파일의 이름의 경우에도 같은 결과 야기 가능 (이는 자료구조를 통해, 즉 구현의 방법을 바꿔가며 해결할 수 있음)
| F (File name) | File의 metadata |
| 1 | |
| 2 | |
| ... | ... |
| n |
* Hash function F (1 <= F(File name) <= n)
3) File의 metadat 보관 위치
a. 디렉토리 내에 직접 보관
b. 디렉토리에는 포인터를 두고 다른 곳에 보관 ex. UNIX(inode), Windows(FAT) 등
* 즉, metadat를 전부 directory가 보관할 수도, 일부는 directory가 가지고 일부는 따로 보관할 수도 있음
4) Log file name의 지원 (긴 파일 이름을 지원하는 방식)
- <file name, file metadata>의 list에서, 각 entry는 일반적으로 고정 크기로 구현함.
* 그러나 가변적으로 활용 될 필요가 있음. (긴 파일의 이름의 경우 비효율성 문제를 해결하기 위해)
- file name이 고정 크기의 entry 길이보다 길어지는 경우, entry의 마지막 부분에 이름의 뒷부분이 위치한 곳의 포인터를 두는 방법
- 이름의 나머지 부분은 동일한 directory file의 일부에 존재
11. VFS and NFS
1) Virtual File System (VFS)
- 서로 다른 다양한 file system에 대해 동일한 시스템 콜 인터페이스(API)를 통해 접근할 수 있게 해주는 OS의 layer
* 즉, file system이 종류가 굉장히 다양(UNIX 파일 시스템, FAT 파일 시스템, 등 ..)한데, 사용자가 각각의 파일 시스템들에 접근할 때 system call을 해야하는데, 파일 시스템 종류별로 다른 인터페이스 시스템 콜을 써야한다면 사용자가 혼란스러울 것임.
* 그래서 어떤 파일 시스템이 사용되던 상관없이, 개별 파일시스템들의 윗 계층에 VFS라는 인터페이스를 사용함으로 인해, 파일 시스템을 쉽게 접근할 수 있도록 도움
2) Network File System (NFS)
- 분산 시스템에서는 네트워크를 통해 파일이 공유될 수 있음
- NFS는 분산 환경에서의 대표적인 파일 공유 방법임
* 파일 시스템이 항상 자기의 스토리지(로컬 파일시스템)에 저장되는 것이 아님. 원격에 저장되있을수도 있음. 원격의 경우 이 인터페이스를 통해 접근이 가능함.
* RPC/XDR : NFS에 대한 접근을 받아줌
* NFS를 지원하려면 client와 server쪽 모두, NFS를 가지고 있어야 함
12. Page Cache and Buffer Cache
1) Page Cache
- virtual memory의 paging system에서 사용하는, page frame을 caching의 관점에서 설명하는 용어
* OS에게 주어지는 정보가 굉장히 적었었음
- Memory-Mapped I/O를 쓰는 경우, file의 I/O에서도 page cache사용
2) Buffer Cache
- 파일시스템을 통한 I/O 연산은 메모리의 특정 영역인 buffer cache 사용
- File 사용의 locality 활용
* 한번 읽어온 block에 대한 후속 요청시 buffer cache에서 즉시 전달
- 모든 프로세스에서 공용으로 사용
- Replacement algorithm 필요 (LRU, LFU 등)
* OS에게 모든 정보가 주어졌음 (hit, miss 모든 경우를 파악 가능)
3) Unified Buffer Cache
- 최근의 OS에서는 기존의 buffer cache가 page cache에 통합됨
4) Memory-Mapped I/O
- File의 일부를 virtual memroy에 mapping시킴
- mapping시킨 영역에 대한 메모리 접근 연산은, 파일의 입출력을 수행하게 함.
* 즉, 프로세스의 주소 공간(virtual memory)중 일부에 파일의 일부를 mapping해놓으면 이후에는 시스템 콜이 아닌, 메모리 접근 연산을 통해 파일 입출력이 가능함.
[ 파일 read/write하는 두 가지 방법 ]
1. Unified Bufffer Cache를 사용하지 않는 File I/O
- I/O using read() and write()를 하면 항상 운영체제로 시스템 콜이 발생함.
- Memory-mapped I/O 시스템 콜을 하면, 자신의 주소공간 중 일부에 파일의 내용을 mapping함.
- 파일을 읽어서 buffer cache에 읽어온 다음, 그 내용을 다시 page cache에 copy해놓음.
* 이후 같은 파일의 내용을 사용자가 요청하게 되면, 시스템 콜이 아닌 read/write 형식으로 바뀜 (사용자 메모리 영역에 올라갔기 때문)
* 만약 접근했는데 해당 파일의 내용이 없으면 page fault가 발생해서 운영체제로 cpu가 넘어가는, 시스템 콜이 발생하게 됨.
** 이 방법이 많은 장점을 가지고 있지만, 파일입출력을 할 때 buffer cache 내용을 page cache로 올려놓는 오버헤드는 존재한다는 단점이 있었음. 따라서 생겨난 해결책이 Unified Buffer Cache를 활용하는 것임.
2. Unified Buffer Cache를 사용한 File I/O
- I/O using read() and write() 시스템콜을 사용할 땐, 마찬가지로 항상 운영체제에게 cpu제어권이 넘ㄴ어감.
- Memory-mapped I/O 시스템콜을 사용하면, 먼저 자신의 주소영역중 일부에 파일의 내용을 mapping하는 단계를 거침. 이후 사용자 프로그램의 주소영역에 page cache 자체가 mapping되었기 때문에, page cache를 사용해 직접 읽고 쓸 수 있음.
13. 프로그램의 실행
주의점 : page cache를 mapping 해놓는 것이기 때문에, 프로세스들이 공유해서 쓰게 되면 일관성의 문제가 발생할 수 있음. (즉, 다른 프로세스들이 그 cache를 쓰는 경우)
* read 시스템 콜에서는 상관이 없음.
| * 유의사항 - 아직 공부하고 있는 문과생 코린이가, 정리해서 남겨놓은 정리 및 필기노트입니다. - 정확하지 않거나, 틀린 점이 있을 수 있으니, 유의해서 봐주시면 감사하겠습니다. - 혹시 잘못된 점을 발견하셨다면, 댓글로 친절하게 남겨주시면 감사하겠습니다 :) |
