[Chapter 11-15]
I. Mass Storage Structure
A. 종류
1. HDD
2. SSD
3. RAM Disk
4. Magnetic Tape
B. Disk Attachment
1. Host Attached: IO포트를 이용해서 슬롯에 바로 디스크를 붙이는것. IDE와 SCSI가 존재한다. IDE는 일반 PC에 사용하는 방식이고 SCSI는 서버와 같은 신뢰성이 중요한 장치에 붙이는 규격이다. 2. Network Attached: NAS, SAN이 있다.
NAS(Network-Attached Storage)는 여러개의 디스크를 넣을수 있는 하드웨어를 네트워크에 연결시켜서 클라이 언트가 네트워크를 통해서 접근할 수 있도록 구현한 스토리지이다. NAS는 하나의 파일시스템과 같이 동작하며 파일레벨로 엑세스할 수 있다. 실제 컴퓨터에 붙어있는 스토리지처럼 사용하며 NFS, CIFS등의 파일 시스템을 사용한다.
SAN(Storage Area Network)은 스토리지를 연결한 네트워크로 NAS보다 큰 단위이다. 네트워크 자체가 하나의 스토리지이며 전용의 interconnection 네트워크를 사용한다. 대량의 데이터를 빠르게 처리해야하는 데이터 센 터 등에서 사용한다. Fiber Channel(광채널)을 사용하고 블록레벨로 데이터를 read/write한다. SAN자체가 하나의 큰 파일시스템이라고 생각할 수 있다. 넷플릭스처럼 대량의 영상데이터 등을 SAN으로 저장한다.
3. 분류: NON IP이면서 direct로 연결되는 IDE,SCSI가 있고 Fiber Channel로 연결된 SAN이 있다. 블록단위로 동 작해서 더 빠르지만 파일시스템을 OS에서 서포트해줘야한다. IP네트워크에는 NAS가 있다. NAS는 별도의 파일 시스템이 존재해서 파일단위로 접근가능하다. 중소규모의 기업에서도 많이 구현해서 사용한다. C. HDD
1. 플래터가 여러장 존재하고 그 위에 데이터를 쓰는 영역인 트랙이 존재. 트랙에 데이터를 쓰는 최소 단위는 섹터, 실제 데이터를 읽는 부분이 헤더, 헤더와 연결된 부분이 암, 암을 움직이는 암 어셈블리 등으로 구성되어 있다. 플래터는 스핀들이라는 공용의 축을 통해서 돌아간다.
HDD는 충격에 약하고 bad block이 잘 발생한다. 피지컬과 로지컬 영역을 나눠서 사용하는데 디스크의 섹터 등은 low level로 피지컬 영역이고 filename, record등 higher level로 abstraction해서 사용한다. 실린더, 트렉 섹 터 등의 정보를 가지고 데이터를 찾는 과정을 전부 OS가 처리하는것은 옛날 방식이고 요즘은 디스크 컨트롤 러에서 처리하며 OS의 오버헤드가 줄어들어 성능이 향상된다. HDD IO에서는 Arm seek time이 성능에 가장 중 요하다. rotation, transfer속도가 미치는 영향은 아주 적다.
seek time을 최대한 줄이기 위한 disk scheduling 알고리즘이 존재한다.
2. Disk Scheduling
● FCFS: 들어온 순서대로 처리한다. 가장 fair하지만 성능이 안좋다.
● SSTF: Shortest Seek-Time First. SJF와 비슷하지만 그와 달리 예측이 가능하다. 제일 가까운 데이터 블 록으로 arm을 움직인다. 큐가 고정되어있으면 starvation발생하지 않지만 새로 계속 들어온다면 starvation이 발생한다. 실제로는 개량된 버전의 sstf를 디스크에서 가장 많이 사용한다.
● SCAN: 엘리베이터 알고리즘이라고도 한다. 한쪽방향의 끝까지 갔다가 반대편의 끝까지 가는 방법. waiting time이 길어진다.
● C-SCAN: SCAN과 달리 waiting time이 균일하다. 한쪽방향으로 끝까지 진행하고 암을 반대쪽 끝으로 초기화하는 방법.
● C-LOOK: 끝까지 가는게 아니라 읽을 데이터가 존재하는 마지막 위치까지 이동하는 방법. C-SCAN을 개량한 방법이다.
3. Disk Controller 기능: Read Ahead (spatial locality를 고려해서 회전하는 방향의 앞의 부분도 미리 읽어서 메 모리에 올려준다.) Caching, Request reordering (운영체제 요청 miss가 난 경우 request를 최적화) Bad block identification ,remapping 등의 기능을 수행한다.
4. Swap-Space Management: Virtual memory를 사용할때 디스크 공간을 메모리의 extension으로 사용. 윈도우 에서는 파일로 관리하는데 C드라이브의 남은 저장공간에서 메인메모리의 2배정도의 공간을 Swap-space로 사 용한다. 그래서 디스크 용량이 90%를 넘어가는 경우 컴퓨터 동작이 느려지기도 한다. 컴퓨터가 느려지면 하드 디스크에 있는걸 지우라고 하는 이유이다.
Linux에서는 별도의 Disk partition을 나눠놓고 swap-space로 사용한다.
D. RAID
1. 정의: Redundant Array of Inexpensive Disks. 여러개의 디스크를 사용해서 성능과 신뢰성을 높이는 방법. 가 격이 싼 스토리지 여러개를 묶어서 배열로 만든다. RAID로 묶으면 여러개의 디스크가 아니라 하나의 큰 디스
크로 인식하게 된다.
2. 신뢰성: Mirroring방법과 Parity, Error-correcting code 방식이 있다.
Mirroring(Shadowing)은 데이터의 완전한 복사본을 만들어놓는다. 하나가 망가져도 복구할 수 있고 필요한 데 이터에 접근할 수 있다. 패리티 비트나 error-correction코드 기법은 깨진 데이터를 복구하기 위한 코드를 저장 해 둔다. 패리티비트는 ECC보다 길이가 짧아서 용량이 작지만 복구범위가 더 적다. 둘 다 복구하기 위해서는 연산이 필요해서 미러링보다는 연산 오버헤드가 크다. 미러링과 패리티비트/ECC를 함께 사용해도 된다.
3. 성능: data striping을 사용해서 성능을 향상시킨다. 데이터를 나눠서 저장하고 불러올 때 병렬적으로 데이터 를 메모리로 올리는 방법이다. 비트레벨과 블록레벨로 나뉜다.
비트레벨은 하나의 디스크 블록을 비트단위로 나눠서 저장하고 일부씩 읽어온다. 양쪽에 독립적으로 명령을 내려서 동시에 읽어올 수 있다. 블록레벨은 특정파일을 블록단위로 나눠서 저장한다. 예를 들어서 넷플릭스에 서 1개의 영상 데이터를 3개의 디스크에 3개의 블록으로 striping해놓고 일부분씩 가져온다면 병목이 발생하지 않고 로드도 분산시킬 수 있다. spatial locality 특성을 살리기 위해서는 블록 레벨이 좋다. 비트레벨은 거의 사 용되지 않는다.
4. RAID 0: 신뢰성은 고려하지 않고 블록레벨의 data striping만 적용해서 성능만 향상. 5. RAID 1: 미러링만 제공해서 신뢰성만 향상. 디스크가 2배로 필요하다.
6. RAID 2: 성능과 신뢰성을 모두 높임. 미러링 대신 error correcting코드를 사용한다. parallelism을 제공하기 위해서 비트레벨로 data striping한다. ECC로 복구도 가능하고 성능도 향상되지만 비트 레벨 striping을 사용해서 잘 안쓴다.
7. RAID 3: ECC는 미러링과 용량에 큰 차이가 없어서 parity code만 적용한 버전. 여전히 비트레벨 striping을 사 용하지만 Storage overhead가 줄어들었다.
8. RAID 4: 비트레벨 striping을 블록레벨로 바꿨고 패리티비트를 사용한다.
9. RAID 5: 패리티 정보를 striping한다. RAID4는 한 디스크에 패리티코드를 몰아놓아서 패리티를 만든 어떤 디 스크에 write해도 패리티 비트를 다시 수정해야하기 때문에 write 작업이 몰린다. 성능에 bottleneck을 없애기 위해서 parity 비트를 분산해서 저장한다. 블록레벨 striping+ 패리티 striping을 적용했다. 10. RAID 6: ECC를 써서 신뢰성을 더 올린다. 패리티비트보다 디스크 용량이 2배 더 사용되어서 디스크 오버헤 드가 크다. 하지만 어차피 디스크는 저렴하기 때문에 실제로 가장 많이 사용하는 방식이다. NAS에서 많이 사용한다.
11. RAID 0+1: RAID0을 먼저 수행해서 블록레벨 데이터 striping을 적용하고 mirroring한다. 12. RAID 1+0: RAID 1으로 미러링 한 이후에 블록레벨 data striping을 적용한다. 순서만 바뀌었지만 성능이 더 좋다. data striping이후 미러링 한 경우에는 디스크 중 하나가 망가졌을때 전체가 망가졌다고 인식해서 망가지 지 않은 디스크도 접근할 수 없다. 하지만 미러링 후 data striping을 적용하면 별개의 레이드로 묶여있기 때문 에 묶인 디스크 두개가 동시에 망가지지 않는 한 접근이 가능하다. 데이터센터 등에서 많이 사용한다.
II. IO Systems
A. CPU -> IO Controller
1. Direct IO vs Memory-mapped IO: CPU가 메모리장치에게 명령을 내리는 방식의 차이
2. IR&DR: CPU가 IO컨트롤러에게 명령을 전달할때 IO 컨트롤러에는 CPU가 내리는 명령을 저장하는 IR레지스터 와 데이터를 저장할 수 있는 DR이 존재한다.
3. graphics controller, SCSI controller, disk controller, memory controller등이 빠른 i/o를 위해서 PCI버스와 연결 되어있고 키보드 등의 느린 IO장치는 expansion버스에 연결되어있다.
B. IO디바이스 명령어 수행
1. Programmed IO: IO장치에서 처리한 결과를 CPU레지스터에 직접 전달하는 방식. IO의 결과 입출력이 적은 키 보드, 마우스 같은 경우 사용한다.
2. Interrupt: IO장치가 처리가 완료되었을때 CPU에게 알려주는 방법
3. DMA: 디스크에서 많은 데이터를 메모리로 로드해야하는 경우 사용. 디스크에 존재하는 DMA컨트롤러가 CPU에게 허락을 받고 이후에는 CPU를 거치지 않고 버스를 통해서 바로 메모리로 데이터를 로드하는 방식 C. Direct IO
1. Intel CPU에서 사용하는 방식. 다양한 IO디바이스 각각에 적합한 Instruction을 CPU에 전부 따로 넣고 명령을 처리하는 레지스터도 별도로 구현. CPU입장에서는 메모리도 IO장치이다. CPU설계상에 Instruction이 핀 형태로 구현되어 수행되기 때문에 IO처리에 불필요한 메모리 사용이 없고 빠른 처리가 가능하다. 하지만 Instruction의 수가 늘어나면 각 IO디바이스 대상으로 명령을 수행하는 버스를 따로 둬야 하고 CPU의 복잡도가 증가하며 생 산가격도 증가한다.
D. Memory Mapped IO
1. ARM코어에서 사용하는 방식. Instruction의 개수가 많아져서 CPU가 복잡해지는것을 방지하기 위해서 가장 많이 사용하는 IO명령인 메모리의 Input Output방식을 다른 디바이스의 IO에도 활용한다. 특정 메모리 영역을 컨트롤러와 연결해놓고 CPU가 디스크 IO를 수행하면 메모리의 특정 영역에 write을 수행하고 그 데이터가 메 모리를 거쳐서 디스크에 저장된다. Direct IO보다 느리지만 MEMR MEMW 명령어 한 세트만 가지고 메모리와 IO명령을 관리할 수 있어서 하드웨어 복잡도가 떨어지고 전력소모도 줄어든다. 어떤 방식을 쓰느냐는 CPU 아
키텍쳐가 CISC인지 RISC인지에 따라서 다르다.
E. Kernel IO Structure
1. 하드웨어 단에 IO디바이스들이 존재하고 각각의 디바이스들의 컨트롤러가 존재한다. 컨트롤러를 소프트웨어 적으로 제어하기 위해서 드라이버라는 시스템 소프트웨어를 컨트롤러마다 제조사에서 제공한다. 드라이버는 특정 하드웨어 dependent한 내용을 다루는 소프트웨어이다. 요즘에는 복잡한 IO장치가 아니라면 Universal Drive가 존재하지만 기능이 많거나 처리할 데이터가 많으면 제조사에서 드라이브를 제공한다. 드라이버들은 IO 컨트롤러에 일대일 매핑된다. Kernel IO서브시스템은 드라이버들의 공통적인 부분들을 표준화하여 처리한다. 프 리징 된 상태에서 클릭 명령이 여러번 중복되어 들어가서 오버헤드가 발생하면 Kernel IO Subsystem은 이미 요청한 것에 대해서 처리가 되었는지 확인하고 동일한 명령을 무시하도록 처리한다. 이러한 빈번한 IO를 중재 하고 커널에서 어떤 드라이버에 명령을 전달할지, 드라이버에서 전달받은 데이터를 어떤 앱에 전달할지 등을 통합해서 관리하는 시스템이다. Device Independent IO Software라고 한다.
F. IO 요청 순서
1. user어플리케이션에서 system call로 요청이 들어오면 커널이 올라오고 커널은 IO서브시스템 함수를 호출한 다. 버퍼 캐시에 요청이 캐싱되어있다면 바로 시스템 콜 요청결과로 전달한다. 캐싱되어 있지 않으면 어떤 드 라이버에 요청을 보낼지 확인해서 요청을 보내고 드라이버는 컨트롤러가 이해할 수 있는 형태로 명령을 내린 다. IO처리가 완료되면 컨트롤러가 인터럽트를 발생시키고 인터럽트 핸들러가 동작하고 인터럽트 핸들러가 드 라이버로 정보를 전달한다. 드라이버는 IO서브시스템 거치지 않고 요청한 어플리케이션에 결과를 전달한다.
2. 채팅 어플리케이션 예시: 키보드로 들어온 데이터로 인해 Programmed IO로 인터럽트가 걸리고 인터럽트 핸들러가 동작한다. 그다음 드라이버로 데이터를 넘겨주고 유저 프로세스로 넘겨준다. 엔터가 입력되면 네트워 크 어뎁터에게 데이터를 보내고 받는 쪽에서도 데이터를 네트워크 데몬에게 보내서 IPC를 통해 유저 프로세스 에 전달한다.
3. IO와 관련된 기능을 구현할때는 프로세싱이 필요없는 하드웨어로 구현하는게 빠르다. SSD컨트롤러가 수행하 는 웨어레벨링 기술이 하드웨어로 구현된 예시다. Abstraction이 좋아지므로 어떻게 구현된건지 알 필요가 없다. 하지만 하드웨어는 변경이 불가능하기때문에 flexibility가 떨어진다.
G. IO System Layers
1. User Process가 커널에 시스템 콜 요청하고 커널은 Device Independent Software = Kernel IO Subsystem에 데 이터를 넘겨주고 공통적인 작업인 Naming, Protection, blocking, buffering등을 수행하고 디바이스에 특화된 동 작을 Device Driver를 통해 수행하고 하드웨어 컨트롤러에게 명령을 전달하면 하드웨어적으로 동작시키고 인터 럽트 발생시키면 인터럽트 핸들러 동작하고 핸들러 유형에 따라 처리하고 디바이스 드라이버에 전달하면 디바 이스 드라이버는 IO서브시스템에 전달하고 IO서브시스템은 유저 프로세스에 전달한다.
네트워크 데이터인 경우에는 4계층에서 세그먼트, 3계층에서 패킷, 2계층에서는 프레임의 구조로 데이터가 캡슐 화되어있는데 physical layer에서는 비트스트림으로 만들어서 전달하고 받은 쪽에서는 디지털화해서 프레임으로 만들고, 모아서 패킷, 세그먼트로 만들어서 어플리케이션 단으로 전달한다. 이러한 capsulation, decapsulation과 정도 드라이버와 Kernel IO서브시스템 동작에 포함된다.
H. Device Independent IO Software
1. Uniform interfacing: 유닉스에서는 모든 io디바이스를 파일기반으로 관리하며 파일 디스크립터를 사용한다. 파일에 있는 내용이 IO디바이스와 연결되어 open, read, write, close등의 시스템콜을 통해 IO디바이스를 어플리 케이션 레이어에서 컨트롤 할 수 있도록 한다.
2. Buffering: 어플리케이션에서 버퍼를 만들어서 사용하는 방법과 커널공간에서 버퍼를 생성하고 어플리케이션 버퍼로 옮겨서 쓰는 방식 등이 있다. 신뢰성이 많이 필요한경우 커널에 더블퍼버를 만들고 어플리케이션 버퍼 로 옮겨서 사용한다.
3. Error reporting: 에러가 발생했을때 서브시스템에서 에러를 받아오고 시스템 콜의 리턴형태로 에러코드를 던 져주고 에플리케이션이 핸들링하는 방법이 있다. ARQ프로토콜은 2계층에서 ACK가 안오면 최대 3번까지 재존 송한다. 메모리에서 corruption이 발생하면 시스템을 강제종료하는 방식을 watch dog이라고 한다. 시스템이 정 지되어있으면 타이머가 동작해서 오랫동안 정지한 상태이면 시스템을 재부팅한다. 하드웨어 dependent한 방식 이다.
4.Block size: 여러개의 섹터를 하나의 logical block으로 처리한다. 1바이트를 사용해도 고정된 블록단위인 4kbyte를 사용한다. 각 디바이스마다 데이터 크기의 단위가 다르면 컨트롤하기 어렵기 때문에 block단위로 처 리한다.
I. User Space IO Software
1. IO처리 인터페이스는 시스템 콜이고 프로그래밍 언어에서 제공하는 라이브러리를 통해 IO처리한다. 2. 스풀링: IO디바이스 중에서도 느린 프린터는 계속해서 요청이 들어오면 job이 처리되지 못하고 쌓인다. 이미 지라서 사이즈가 크기 때문에 피지컬 메모리도 많이 사용한다. IO처리시에 필요한 데이터를 메모리에서 보관하 는것이 아니라 파일로 만들어놓으면 좋다. 디스크에 저장되어있어도 프린터 자체의 속도가 느리기때문에 상관
없다. 용량이 큰 작업에 IO디바이스의 속도가 느려서 메모리를 많이 차지하는 경우 task를 파일로 저장해놓는 것을 스풀링이라고 한다.
III. File System Interface
A. 파일
1. 정의: 파일은 관련된 정보들의 집합. 세컨더리 스토리지에 저장하는 단위이다. 파일에는 아무것도 작성하지 않아도 EOF라는 특수문자가 들어있고 파일에 텍스트를 넣고 저장하면 마지막 위치로 EOF를 시프팅해서 옮 긴다. 오픈할때는 EOF의 바로 앞이 파일 포인터가 된다. 파일 포인터를 특정 위치로 이동시키는것이 seek이 다.
2. 파일 시스템: 파일 시스템은 데이터를 long term으로 저장하기 위해서 존재하는 운영체제의 서브시스템. 윈도 우는 파일시스템으로 NTFS를 사용하고 리눅스는 ext를 사용한다. USB는 FAT을 사용한다. FAT과 NTFS의 가 장 큰 차이는 안정성으로 NTFS가 안정성이 더 좋다. 파일 시스템콜로 create, open, close, read, write, chmod, chown 등이 있다. 하지만 c등의 언어 내부에서 사용되고 인터페이스를 제공하므로 직접 사용하는 경우는 거의 없다. 파일시스템은 permission, 파일 저장, 디렉토리로 logical 구조를 만들고 권한설정 및 protection 등의 작업을 한다.
B. File Type
1. 파일 시스템의 분류: device, directory, symbolic link 등
2. OS의 특정파트 혹은 런타임 라이브러리: executable, dll, object code, text 등. 커널이 몰라도 특정 시스템 프 로그램이 인식해야한다.
3. Application program이 구분: jpg, mpg, avi,mp3 등.
4. 윈도우는 확장자로 인코딩을 한다. 정확한 확장자가 필수이다. 하지만 리눅스는 확장자 개념이 없고 컴파일 러와 소스코드의 약속이다.
C. Directory
1. 여러 형태의 파일들의 리스트 정보를 저장할 수 있는 특수한 파일. hierarchical한 구조를 가지고 경로를 가 진다. 어떤 파일들이 어느 위치에 저장되어있는지를 보여줄 수 있다. 경로의 개념이 생기고 효과적인 임의접근 이 가능하다. 현재위치를 기준으로 하면 상대경로, 루트부터 시작하면 절대경로이다. 디렉토리는 filename과 attribute의 리스트이다. attribute는 리스팅하고 있는 파일의 크기, protection정보, 생성일, 수정일, 디스크에서의 위치 등을 포함한다. 리스팅되어있는 파일들은 랜덤엑세스되기 때문에 정렬되어있지 않고 임의의 순서대로 들 어간다.
D. File System Mounting
1. 새로 디스크를 연결할때 유닉스 계열에서는 비어있는 디렉토리에 끼운다. 루트 밑에 설치된다. ./usr/dev에 마운팅 된 디바이스들을 접근할 수 있다. 윈도우는 물리적인 디스크들이 다른 레터링을 가지고 독립적으로 존 재함. C드라이브, D드라이브 등 디바이스마다 루트가 따로 존재한다.
E. Remote File System
1. 다른 컴퓨터의 파일 시스템을 원격으로 접근하는 방식. 유닉스는 NFS, 윈도우는 CIFS를 사용. F. Protection
1. 윈도우에서는 개인 PC로 많이 사용하기때문에 중요하지 않지만 유닉스 시스템은 다수의 유저들이 접근해서 사용하기 때문에 보안과 권한이 중요하다. ACL Access Control List방식과 Capability방식이 존재한다. ACL은 파 일당 권한설정이고 Capability는 사용자당 파일 권한 설정하는 방식이다. 파일수가 많기 때문에 리눅스에서는 ACL을 사용한다. Owner Access, Group Access, Public Access로 구분되며 각각이 RWX(Read, Write, Execute)권한 이 8진수로 지정되어있고 chmod를 통해서 권한을 변경할 수 있다. ls -l명령어를 통해서 권한을 확인할 수 있 다. 유저아이디, 그룹 용량 변경시간 파일이름을 확인할 수 있다. d는 directory임을 가리킨다.
G. Memory mapped File
1. 파일에 있는 데이터 읽으려면 c++의 경우 fstream 객체 만들고 open r/w 후 close인데, 이런식으로 사용하 지 않고 file데이터를 address space에 매핑시키는 방법이다. write을 하면 disk에 write을 수행하도록 한다. mmap 시스템콜을 사용한다.
IV. File System Implementation and Internals
A. In-memory 구조
1. 특정 프로세스가 파일에 접근하기 위해서 open을 수행하면 file descriptor가 반환된다. 이걸 가지고 read write을 수행한다. 여러개의 프로세스들이 파일을 접근할때 운영체제는 system-wide open file table을 운영한 다. 전체 프로세스들의 open file들을 관리하는 테이블이다. 각 프로세스들은 각각 자신의 open file에 대해 per-process file descriptor table을 PCB에서 관리하고 중복되지 않도록 운영체제의 system wide open file table의 요소를 가리키고 있다. 유닉스 계열은 파일뿐만 아니라 io디바이스들도 descriptor로 관리한다. 프로
그램 실행되면 기본적으로 3개의 파일 stdin, stdout, stderr을 오픈한다. 디스크를 매번 접근하면 성능이 떨어 지므로 자주 사용하는 파일들은 캐시에 올려놓는다. in-memory partition table은 superblock, 비트맵, i-node 등의 정보를 저장하고 directory cache는 디렉토리 정보, 실제 파일 내용은 buffer cache에 담는다. 보통 이 3 가지를 통칭해서 buffer cache라고 부른다.
2. VFS: Virtual File System: 파일 시스템의 공통적인 부분을 묶은것. 구체적인 파일 시스템은 아래에 더 붙여서 사용한다. CD-ROM은 ISO9660을 사용하고, 유닉스는 UFS, 윈도우는 FAT,NTFS, 리눅스는 ext2/3/4를 사용. buffer cache는 공유해서 사용한다.
B. On-Disk구조
1. MBR: 부트로더가 저장됨. 운영체제를 메모리로 올려주는 코드가 들어있는 펌웨어이다. 파티션별로 다른 운 영체제를 설치할 수 있다. 부트로더는 어떤 운영체제로 부팅할것인지 선택할 수 있다.
2. boot block:부팅에 필요한 것들을 저장하는 블록. 해당 파티션에 운영체제가 저장되지 않으면 존재하지 않는 다. 윈도우에서는 boot sector라고 부름.
3. super block:파일시스템 전체에 대한 정보를 가지고 있다. 블록의 개수, 파일시스템 타입, 얼마만큼 사용되고 있는지 등. 윈도우에서는 master file tabled이라고 부름. 섹터의 크기는 512바이트이지만 섹터크기로 관리하려 면 운영체제의 오버헤드가 너무 크기 때문에 4kbyte인 블록 단위로 관리한다. 디스크 블록 0번은 가장 위의 플래터의 가장 바깥 트랙의 섹터부터 사용한다. 하나의 블럭이 4kbyte이므로 8개의 섹터를 사용한다. 다음 블 록은 같은 실린더 상의 트랙에 쓴다.
4. bitmaps: 존재하는 디스크 블록들이 사용중인지 정보를 저장해놓는 블록이다. 0,1 값으로 관리한다. 5. i-nodes: 각 파일에 대한 메타데이터. FCB(File Control Block)이다. 이름, permission, owner, access정보 등을 관리한다. 유닉스 시스템에서는 i-node라고 부르는것이다. 파일별로 i-node는 하나씩 존재한다. FCB는 보통 4kbyte이다.
6. root dir: 루트 디렉토리 주소. hierarchical한 디렉토리 구조 만드는 기준.
7. file & directories: 실제 데이터 저장되는 부분. 연속적으로 저장하면 hole이 생긴다. fragmentation이 발생한 다. 데이터가 바뀌지 않는 CD,DVD,블루레이의 경우는 연속적으로 데이터를 기입해도 문제가 없지만 하드디스 크는 안된다.
C. FCB:
1. File Control Block은 유닉스에서는 i-node라고 하고 윈도우에서는 master file table이라고 부른다. file permission, dates(create, access, write), owner, group, ACL, size 등의 정보가 들어간다. 파일을 만들때 생성되며 파일의 최소단위는 1블록으로 4kbyte, FCB도 4kbyte이므로 최소 총 8kbyte를 차지한다. D. Directory Implementation
1. 디렉토리 안에 존재하는 모든 파일들의 FCB를 다 넣는 방법.
2. 파일 이름과 FCB를 가리키는 포인터만 저장하는것 – 유닉스 방식(i-node)
3. hybrid approach: 중요한건 디렉토리에 저장하고 나머지는 FCB를 가리키는 포인터로 관리 – 윈도우 방식 E. Allocation Method
1. 정의: 디스크 내의 블록들을 관리하고 배치하는 방법
2. Contiguous allocation: 연속적으로 블록들을 배치. 시작위치와 길이정보만 가지면 된다. 한번에 많이 읽어올 수록 spatial locality도 좋기 때문에 효율적이다. 단점은 Fragmentation이 발생한다. 데이터가 변하지 않는 경우 는 성능이 우수하다.
3. Linked Allocation: 블록에 포인터를 주고 다음 블록을 가리키게 하고, 마지막인 경우 NULL. external fragmentation이 없어지고 파일크기가 가변적이어도 상관없음. 파일이름과 시작위치만 저장하면 된다. 단점은 spatial locality가 떨어지고, 포인터가 중간에 하나라도 깨지면 데이터가 날아가기 때문에 신뢰성이 낮다. 개선 된 형태로 별도의 블록에 포인터 정보만 따로 저장하는 방법도 있다. 한 블록에 포인터 정보를 몰아넣은것을 복사본을 만들어서 신뢰성을 향상시키고 디스크 스케줄링에도 효과적이다. 개선된 형태의 linked Allocation을 사용하는 파일 시스템이 FAT(File-Allocation Table)이다.
4. Indexed Allocation: 블록별로 포인터를 두지 않고 블록에 정수 인덱스를 부여하고 인덱스 블록에서 관리하 는 방법. 중간에 파일이 손상되어도 그 파일 외에는 접근 가능하므로 신뢰성이 높다.
5. i-node: 파일에 대한 메타 데이터를 저장하는 FCB이며 i-node에서 데이터 블록을 가리키는 방법은 direct와 indirect방법이 있다. direct block들은 12개밖에 없고 각 블록은 4kbyte이므로 48kbyte까지만 저장 가능하다. 대 부분의 파일들이 50kbyte를 넘지 않기 때문에 12개가 존재한다. 크기를 넘어가는 경우 multilevel index block을 사용하는데 single indirect에서 1000개의 data block을 가리키는 i-node를 가리키도록 구현되어 4MB까지 저장 이 가능하다. 넘어가면 double indirect로 1000개의 i-node를 가리키는 i-node의 주소를 가리키고 그 i-node들 은 다시 1000개의 i-node를 가리키므로 4GB까지 저장이 가능하다. triple indirect도 존재한다. Triple Indirect가 없는 경우 파일의 최대크기는 4GB정도가 되며 이를 넘어가면 여러개의 파일로 분할해야한다.
F. UFS구조
1. /bin/a.out을 실행한다면 루트의 i-node를 읽고 i-node가 디렉토리를 가리키고 bin이 저장된 블록을 찾고 그 블록을 읽어서 디렉토리 정보가 11000번에 있어서 또 이동. a.out이 500번 블럭에 저장되어 있으니 500번 인덱스의 i-node를 읽어옴. a.out의 i-node에서 12개는 direct block, 650번은 12개의 블럭으로 모자라서 single indirect block을 할당해서 650번 i-node를 읽어와서 데이터를 접근한다. 여러명의 사용자가 동일한 파일을 읽 으면 오버헤드가 발생하므로 directory cache, buffer cache에 데이터를 캐싱한다. read성능이 개선된다. 캐시 데 이터가 메모리에 존재하고 해당 데이터가 변경되었을때 디스크와의 consistency를 유지하는 방법으로는 write through와 write back이 있다. write through는 성능이 떨어져서 write back을 수행한다. 비정상적 종료하는 경 우 inconsistency가 발생할 수 있다.
G. Block Size
1. data rate, Disk space Utilization을 고려했을때 가장 적합한 크기는 4kbyte이다.
H. Read Ahead
1. Spatial locality를 활용해서 현재 엑세스하는 부분 근처의 데이터를 미리 읽어오면 성능을 항샹시킬 수 있다. 하드디스크는 arm seek의 오버헤드가 크기 때문에 많이 읽어오면 성능에 좋다.
I. Reliability
1. 디스크는 신뢰성이 중요한데 성능을 위해서 버퍼캐시를 사용하다보면 reliability가 깨지는 상황이 발생할 수 있다. 그런 상황을 대비해서 윈도우에서는 scandisk, 유닉스는 fsck 명령어가 존재함.
2. Log Structured File System: Journaling file system이라고도 한다. write이 수행되면 디스크에 로그를 쓴다. 시 스템이 유휴상태가 되어서 디스크에 write back되면 journal을 지운다. 재부팅될때 로그 파트를 보고 비어있으
면 inconsistent하지 않은 상황이고 남아있다면 문제가 발생한것으로 보고 로그 데이터를 바탕으로 복구를 수 행한다.
J. NFS
1. Network File System: 내 컴퓨터에 존재하는 디스크처럼 네트워크를 통해서 파일시스템을 사용할 수 있다. NFS서버 프로그램이 존재하고 네트워크를 통해서 전달받고 클라이언트에서는 VFS인터페이스 아래에 NFS클라 이언트가 존재해서 데이터를 전달받는다.