[OS 기초] 운영체제와 파일시스템

[ 우선순위 역전 현상 (Priority Inversion) ]

우선순위가 높은 태스크(T1)가 낮은 태스크(T2) 보다 늦게 실행되는 스케줄링의 모순 현상입니다. 공유 자원(Mutex, Semaphore)을 사용하는 멀티태스킹 환경에서 발생

 

발생 과정 (필기 이미지 흐름 분석):

• 전제: 우선순위는 T1 > T2 > T3 순서

1. T3 실행 및 자원 획득: 가장 낮은 우선순위인 T3가 먼저 실행되어 Mutex(공유 자원)를 획득한다.
2. T1 진입 및 Block: 높은 우선순위인 T1이 진입하여 Mutex 획득을 시도하지만, 이미 T3가 점유 중이므로 Block(대기) 상태가 된다.
3. T2 진입 및 역전 발생: 중간 우선순위인 T2가 진입합니다. T2는 Mutex가 필요 없으며, 현재 실행 가능한 T3보다 우선순위가 높으므로 T3를 선점(Context Switching)하여 실행된다.
4. 결과: T1(고)은 T3(저)가 자원을 놓기만을 기다리는데, 갑자기 T2(중)가 CPU를 차지해 버려 T1이 T2보다 늦게 실행되는 역전이 발생한다.

 

해결 방안 (Protocol)

문제를 해결하기 위해 두 가지 프로토콜을 제시

구분	우선순위 상속 (PIP)(Priority Inheritance Protocol)	우선순위 상한 (PCP)(Priority Ceiling Protocol)
핵심 원리	자원을 점유한 T3의 우선순위를 일시적으로 T1(가장 높은 놈)만큼 격상시킴.	공유 자원 자체에 최고 우선순위(Ceiling)를 부여함. 자원을 잡는 순간 그 우선순위가 됨.
효과	T3의 우선순위가 높아졌으므로, T2가 T3를 선점하지 못함. T3가 빨리 일을 마치고 자원을 반납하면 T1이 실행됨	진입 시점부터 최고 우선순위를 가지므로 스위칭 자체가 발생하지 않음
특징	• 구현이 비교적 단순함 • 범용 OS에서 주로 사용 • 단점: 교착 상태(Deadlock) 발생 가능성 있음	• 구현과 설계가 복잡함 • RTOS(실시간 OS)에서 주로 사용 • 장점: 교착 상태(Deadlock) 예방 가능

 

리눅스 커널이 제공하는 가장 중요한 시스템

: 프로세스, 메모리, 파일, 시스템, 네트워크, 디바이스, IPC 

 

모놀리식 운영체제는 단일형 커널 구조로, 입출력, 네트워크, 장치 지원 등 운영체제의 거의 모든 기능을 단일 메모리 공간에서 실행

확장자에 따라 특정 애플리케이션 구동

 

[ 파일(File)의 기본 개념 ]

1) 정의 및 관점

• 추상적 정의: 데이터를 표현하기 위한 추상적인 방법. 컴퓨터상의 디지털 정보(0과 1)를 인간이 이해하기 쉬운 형태(이미지, 문서, 동영상 등)로 접근하게 해주는 개념
• 개념적 관점: 정보의 집합 또는 데이터 청크(Chunk)
• 물리적 관점: 저장 장치에 존재하는 비트(Bit)나 바이트(Byte)의 나열
• 논리적 관점: 의미 있는 정보를 담고 있는 논리적인 단위

2) 운영체제(OS)의 역할

• 운영체제는 파일 조작을 위한 기능을 API(System Call) 형태로 제공

[ 파일 식별 및 운영체제별 특징 ]

파일을 구분하는 방법(확장자, 대소문자)은 운영체제마다 차이가 있다.

구분	Windows	Linux / Unix	macOS	Android
확장자 역할	필수적. 확장자에 따라 연결 프로그램(Registry)이 결정됨	참고용. 파일 내용이 중요하며 확장자는 편의상 사용(실행 여부에 영향 X)	(포맷 설정에 따름)	파일 실행 시 적합한 앱 목록(Intent)을 팝업으로 띄워 선택 유도
대소문자 구분	구분하지 않음	엄격하게 구분 (다른 문자로 취급)	포맷 시 선택 가능	(Linux 커널 기반이라 구분 함)

 

[ 파일의 유형 (Text vs Binary) ]

파일의 저장 방식과 목적에 따라 크게 두 가지로 분류

① 텍스트 파일 (Text File)

• 특징: 사람에게 보여주기 위한 목적
• 형식: ASCII 코드, 유니코드 등 문자로 표현 가능한 데이터
• 열람: 메모장(Windows), VI/Emacs(Unix/Linux) 등 일반 텍스트 편집기로 내용 확인 가능
• 보안: 파일만 유출되어도 누구나 내용을 읽을 수 있음

② 이진 파일 (Binary File)

• 특징: 저장과 기계적 처리를 목적으로 0과 1로 인코딩 된 데이터
• 형식: 전용 포맷(Format)을 따름. (예: hwp, doc, xls, ppt, jpg, exe 등)
• 열람: 텍스트 편집기로 열면 깨진 문자(알 수 없는 문자)로 보임. 반드시 전용 소프트웨어(Word, 뷰어 등)가 필요
• 구성:
  • 헤더(Header): 파일의 메타데이터(전체 크기, 버전, 데이터 구조 정보 등)
  • 데이터(Content): 실제 콘텐츠(텍스트 + 이미지 + 기타 정보 혼합)

 

[ 왜 바이너리(Binary)로 저장하는가? (프로그래밍 관점) ]

바이너리 저장의 필요성 및 효율성에 대한 내용

1. 복합 데이터 처리: 문서 내에 텍스트뿐만 아니라 이미지, 동영상, 표 서식 등 다양한 데이터가 혼재될 경우 텍스트로만 표현하기 어렵다.
2. 저장 공간 효율:
3. 처리 속도: 컴퓨터가 바로 연산 가능한 형태이므로 별도의 파싱(Parsing) 과정이 줄어들어 처리가 용이하다.
4. 보안성: 포맷(구조)을 모르면 내용을 쉽게 열람할 수 없어 기본적인 데이터 보호 효과가 있다.

 

[ 파일의 식별과 시그니처 ]

1. 파일의 식별 (File Identification)

파일의 유형을 어떻게 구분하는지는 사용자와 운영체제(시스템) 간에 차이가 있다.

• 사람(User)의 식별 방식:
  • 주로 파일의 이름과 확장자(Extension)를 보고 유형을 판단
  • 예) . jpg,. txt,. exe 등을 보고 실행할 프로그램을 결정함.
• 운영체제(OS) 및 분석 도구의 식별 방식:
  • 매직 넘버(Magic Number) 또는 파일 시그니처(File Signature)라고 불리는 고유한 값을 사용하여 구분한다.
  • 확장자가 변조되어도 파일 내부의 고유 값을 통해 정확한 유형 판단이 가능하다.

2. 파일 시그니처 (File Signature) 상세

• 위치 및 크기:
  • 주로 파일 헤더(Header)의 시작 부분이나 파일 끝(Footer) 부분에 위치함
  • 크기는 보통 2~4 Bytes 정도의 고유한 16진수 값으로 구성됨
• 대표적인 예시 (JPEG 파일):
  • 헤더 시그니처: FF D8 FF E0 또는 FF D8 FF E1
• 참고 자료:
  • Gary Kessler의 File Signature Table (전 세계 대부분의 파일 시그니처가 정리된 DB).

3. 보안 및 포렌식 관점의 중요성

1) 확장자 변조와 은닉 (Obfuscation)

• 시나리오: 윈도우 환경에서 image.jpg의 확장자를 image.txt로 강제로 변경함.
• 결과: 사용자가 실행 시 메모장이 열리며 내용을 알아볼 수 없게 됨(깨진 문자 출력).
• 의미: 일반인 수준에서는 단순히 확장자를 바꾸는 것만으로도 파일의 정체를 숨길 수 있지만, 전문적인 분석에서는 통하지 않는 기법

2) 정밀 분석과 검증

• 확장자는 겉표지에 불과하므로, 파일의 실제 헤더 시그니처를 확인해야만 정확한 파일 유형을 판별할 수 있다.

3) 파일 카빙 (File Carving)

• 정의: 디스크의 비할당 영역(삭제된 데이터 등)에서 파일 시스템 메타데이터 없이 오직 파일의 시그니처(헤더/푸터)만을 이용해 파일을 복구해 내는 기법
• 디지털 포렌식 조사의 핵심 기술 중 하나

 

[ 파일의 상태 정보 ]

모든 파일은 파일 내부에 저장된 실제 데이터(Content) 외에도, 관리와 제어를 위한 상태 정보(메타데이터)를 별도로 유지

• 주요 속성 (Attributes):
  • 기본 정보: 파일 이름, 파일 종류(Type), 파일 크기(Size)
  • 시간 정보 (Time Stamps):
    • 생성 시간 (Created Time)
    • 최근 접근 시간 (Last Accessed Time)
    • 최근 갱신 시간 (Last Modified Time)
  • 보안 및 소유: 파일 소유자(Owner), 접근 권한(Permissions)
  • 위치 정보: 파일의 물리적 저장 위치 (Physical Location)

 

운영체제별 관리: i-node (Linux/UNIX)

운영체제마다 이 상태 정보를 관리하는 방식이 다르다. 강의에서는 Linux(UNIX 계열)의 방식을 강조

• i-node 구조체:
  • 리눅스 등 유닉스 계열 운영체제는 파일의 메타데이터를 inode (Index Node)라는 특수한 구조체에 저장하여 관리
  • 파일의 '내용'과 '정보'를 분리하여, 실제 데이터 블록의 위치와 파일 속성을 inode가 가리키는 구조

 

[ 파일의 구성 ]

1. 데이터의 계층 구조 (Data Hierarchy)

데이터는 가장 작은 단위부터 거대한 집합까지 계층적으로 구성

1. 필드 (Field/Column): 의미 있는 정보를 담는 최소 논리적 단위 (예: 학번, 이름).
2. 레코드 (Record): 연관된 필드들의 집합. 한 행(Row)에 해당. (예: 학생 1명의 전체 정보).
3. 파일 (File): 레코드들의 집합. (예: 정보보안공학과 1학년 전체 명단).
4. 데이터베이스 (DB): 파일들의 집합.

---

2. 필드 설계와 데이터 타입 결정 (Student 예시)

데이터 타입(Primitive Type)을 결정할 때는 데이터의 성격(연산 필요 여부, 길이 가변성)을 고려해야 함

DataType : char, int, float, … (Primitive Type) → 학생의 정보를 표현

C, C++, Java

학생 column(field)

필드명 (Column)	학번 (Student ID)	학과명 / 학과코드 (Department)	성명 (Name)	전화번호 (Phone)	주소 (Address)	사진 (Photo)
데이터 성격	길이가 고정된 숫자 또는 문자	분류를 위한 코드 정보	사람의 이름 (길이 다양)	연락처 숫자	거주지 정보 (길이 매우 다양)	비정형 바이너리 데이터
고려 사항	• 산술 연산 불필요 • 학번 내부의 의미(입학연도, 단과대 등) 존재 • 정수형(long 4B) vs 문자열(char 8B) 고민 필요	• 단순 코드화 가능 (예: 2자리 정수)	• 한국인: 보통 3글자 • 외국인: 4글자 이상 등 다양함	• 하이픈(-) 포함 여부 (11~13자리) • 숫자가 아닌 문자로 취급하는 것이 유리	• 사람마다 주소 길이가 천차만별임	• 규격(4x3) 제한 없으면 크기 제각각 • 레코드 내 직접 저장 불가
최적 타입	고정 길이 문자열 (Fixed Char)	1 Byte 정수 (Tiny Int / Byte)	가변 길이 문자열 (Variable String / Varchar)	문자열 (String / Char)	가변 길이 문자열 (Variable String)	BLOB (Binary Large Object)

---

3. 레코드의 형태 (Record Types)

파일 내 레코드를 구성하는 방식은 크게 두 가지로 나뉨

• 고정 길이 (Fixed Length):
• 가변 길이 (Variable Length):

---

4. 구조적 vs 비구조적 데이터 (BLOB)

데이터의 형태에 따라 저장 방식이 완전히 달라짐

① 구조적 데이터 (Structured Data)

• 정형 데이터: 정수, 실수, 문자열 등 표준 데이터 타입으로 표현 가능.
• 미리 정의된 틀(Schema)에 맞춰 차곡차곡 저장된다.

② 비구조적 데이터 (Unstructured Data) - BLOB

• 정의: BLOB (Binary Large Object). 이미지, 비디오, 오디오, 텍스트 등.
• 특징: 크기가 제각각이라 레코드 내부에 직접 저장하기 어렵다. (예: 4x3 사진 규격 제한이 없으면 필드 길이가 폭증함)
• 저장 방식:
  1. 실제 데이터는 별도의 '디스크 블록 풀(Pool)'에 저장
  2. 레코드에는 해당 데이터가 저장된 위치를 가리키는 포인터(Pointer)만 포함.

 

[ 물리적 저장 구조 vs 논리적 저장 구조 ]

운영체제는 하드웨어의 복잡한 물리적 구조를 추상화(Abstraction)하여 관리

① 하드디스크(HDD)의 물리적 구조

하드디스크를 분해해 보면 위 이미지와 같은 구조를 가진다.

• 플래터 (Platter): 데이터가 저장되는 은색 원판. 여러 장이 겹쳐 있을 수 있다.
• 트랙 (Track): 플래터 표면의 동심원
• 섹터 (Sector): 트랙을 부채꼴 모양으로 쪼갠 가장 작은 물리적 저장 단위 (보통 512 Byte)
• 실린더 (Cylinder): 여러 장의 플래터에서 동일한 위치에 있는 트랙들의 집합
• 동작: 액추에이터 암(Actuator Arm)이 물리적으로 이동하며 특정 섹터를 찾아 데이터를 읽고 쓴다

② SSD(NAND Flash)의 특성

SSD는 HDD와 달리 물리적으로 회전하지 않지만, 삭제(Erase) 횟수 제한이라는 치명적인 특성이 있다.

• 읽기/쓰기 단위: 페이지(Page) 단위
• 삭제 단위: 블록(Block) 단위 (삭제 단위가 더 큼)
• 문제점: 데이터 수정 시 덮어쓰기가 불가능(Overwrite 불가). 지우고 새로 써야 하는데, 지우는 건 블록 단위라 비효율적이며 수명을 깎아먹음.
• 해결책 (Wear Leveling): 데이터를 제자리에 덮어쓰지 않고, 새로운 위치에 쓰고 기존 데이터는 'Invalid' 처리. 특정 블록만 닳는 것을 방지하여 수명을 연장하는 기법

 

③ 논리적 단위: 블록 (Block)

사용자는 위와 같은 물리적 특성(섹터, 페이지, 웨어레벨링 등)을 몰라도 된다. 파일 시스템이 이를 블록(Block)이라는 논리적 단위로 통합해서 보여주기 때문이다.

• 정의: 운영체제(파일 시스템)와 저장 장치 간의 데이터 전송 단위
• 매핑: 파일 시스템은 물리적인 섹터 여러 개를 묶어 하나의 블록(예: 1KB, 4KB)으로 관리한다.

 

[ 블록 크기와 성능의 Trade-off ]

포맷할 때 블록의 크기(1KB, 4KB 등)를 설정할 수 있는데, 이는 공간 효율성과 속도 사이의 딜레마(Trade-off)가 있다.

구분	블록 크기가 작을 때 (ex. 1KB)	블록 크기가 클 때 (ex. 4KB)
공간 효율성	좋음 (파일 끝부분에 남는 낭비 공간인 '내부 단편화'가 적음)	나쁨 (작은 파일 저장 시 낭비 공간이 커짐)
속도 (I/O 횟수)	나쁨 (3KB 파일을 읽으려면 3번 접근해야 함)	좋음 (3KB 파일을 1번에 읽을 수 있음)
결론	과거에는 저장 공간이 비싸서 작게 썼으나, 현대에는 성능(속도)이 더 중요하므로 블록을 크게 잡는 추세

 

블로킹 인수(Bf:Blocking factor) : 각 블록에 저장 가능한 레코드의 평균 개수 (Bf = B/R) - B: 블록의 크기

[ 리눅스 파일 시스템의 계층 구조 (VFS) ]

사용자가 파일 시스템의 종류(EXT2/3/4, FAT, NTFS, JFFS, YAFFS 등)나 저장 장치의 종류(HDD, SSD)를 신경 쓰지 않고 똑같은 read(), write() 함수를 쓸 수 있는 이유는 VFS(Virtual File System) 덕분이다.

 

[ User Application ]

↓ read() / write() 호출

[ VFS (Virtual File System) ] (가상 파일 시스템 계층: 모든 파일 시스템을 공통된 인터페이스로 추상화)

↓ 적절한 파일 시스템으로 분기

[ File System Layer ] (JFFS/YAFFS(플래시용) 또는 ext4(리눅스), NTFS/FAT(윈도우) 등)

↓ 논리적 블록 요청

[ Block Device Driver ] (하드웨어 제어: 물리적 섹터/페이지 접근)

↓

[ Hardware (HDD / SSD) ]

• 작동 원리:
  1. 사용자가 read(fd)를 호출하면 VFS가 받는다.
  2. VFS는 해당 파일이 어떤 파일 시스템(ex. ext4)에 있는지 확인하고 해당 드라이버의 읽기 함수를 호출한다.
  3. 최종적으로 디바이스 드라이버가 물리 디스크의 섹터를 읽어온다.

 

[ 추상화 과정 예시 ]

1. /home/text 파일 저장 예시

교수님은 3KB 크기의 파일을 저장하는 상황을 가정하여, 우리가 보는 논리적 뷰(파일 시스템)와 실제 물리적 뷰(디스크)의 차이를 설명하셨습니다.

• 상황: 사용자가 /home/text라는 이름으로 3KB 크기의 데이터를 저장하려고 함.
• 물리적 관점 (Hard Disk):
  • 섹터 크기가 512 Byte라면, 총 6개의 섹터가 필요 (512B \times 6 = 3KB)
  • 문제는 이 6개의 섹터가 디스크상에 연속으로 있지 않고 여기저기 흩어져 있을(단편화) 수 있다. (예: 1번 트랙, 5번 트랙 등)
  • 만약 파일 시스템이 없다면, 사용자가 일일이 "1번 트랙 3번 섹터에 앞부분 저장하고..."라고 명령해야 한다.
• 논리적 관점 (File System):
  • 파일 시스템은 이를 블록(Block) 단위로 퉁쳐서 관리한다. (블록 크기가 1KB라고 가정)
  • 사용자에게는 "이 파일은 3개의 블록(Block 1, 2, 3)에 저장되었다"라고만 알려준다.
  • 결과: 사용자는 물리적으로 섹터가 어디에 흩어져 있는지 전혀 신경 쓰지 않고, /home/text라는 이름만으로 파일에 접근할 수 있다.

2. Block Device Driver의 역할 (read 함수 호출 흐름)

사용자가 read() 함수를 호출했을 때, 이 명령이 어떻게 타고 내려가서 하드웨어를 건드리는지 보여주는 흐름. 이 과정에서 VFS와 디바이스 드라이버의 역할이 명확해진다.

1. User Application: read(fd) 함수 호출 (파일 읽기 요청)
2. System Call Interface: 커널 영역으로 진입.
3. VFS (Virtual File System):
   • "이 파일(fd)이 어느 파일 시스템 소속이지?"를 판단
   • 만약 ext4라면 ext4_read()를, 플래시 메모리라면 jffs_read()를 호출하도록 분기해 준다. (공통 인터페이스 제공)
4. File System (e.g., ext4) :
   • 논리적인 블록 번호를 계산한다. ("이 데이터는 10번 블록에 있다.")
5. Block Device Driver :
   • 파일 시스템이 요청한 논리적 블록을 실제 물리적 주소(섹터/페이지)로 변환한다.
   • 실제 하드디스크의 헤드(Arm)를 움직이거나, SSD 컨트롤러에 신호를 보내 데이터를 가져온다.
   • 역할: 하드웨어(HDD, SSD)마다 제어 방식이 완전히 다른데, 이 기계적인 차이를 처리해주는 것이 바로 디바이스 드라이버다.

 

[ 레코드 저장 방식 ]

1. 레코드 저장 방식: 비신장 vs 신장

레코드(R)를 블록(B)에 담을 때, "레코드가 블록의 경계를 넘어갈 수 있느냐?"가 기준입니다.

구분	비신장 조직 (Unspanned)	신장 조직 (Spanned)
개념	레코드가 블록의 경계를 넘지 않음	레코드가 블록의 경계를 넘어감 (나누어 저장)
저장 방식	블록에 레코드를 채우다가 남는 공간이 레코드보다 작으면, 그 공간을 버리고 다음 블록에 새 레코드를 씀	블록의 마지막 공간까지 꽉 채우고, 잘린 나머지 부분은 다음 블록에 이어서 저장함
조건	주로 $R < B$ (레코드가 블록보다 작을 때)	$R > B$ (레코드가 블록보다 클 때) 또는 공간 효율이 중요할 때
관리	단순함. (오프셋만 알면 됨)	복잡함. 이전 블록의 끝에 "다음 데이터는 O번 블록에 있음"이라는 포인터(Pointer)가 필요함 (Linked List 형태)
장단점	• 장점: 속도 빠름 (블록 하나만 읽으면 됨) • 단점: 여유 공간(낭비) 발생	• 장점: 공간 낭비 없음 (알뜰함) • 단점: 속도 느림 (여러 블록을 읽어야 함)

---

2. 가변 길이 레코드의 처리 (Variable-Length)

레코드의 길이가 들쑥날쑥할 때(학생 이름, 주소 등), 컴퓨터가 어디서부터 어디까지가 하나의 필드인지 알 수 있게 하는 방법

1) 헤더(Header) 활용

• 파일이나 레코드의 앞부분(Header)에 메타데이터를 기록
• 예: "첫 번째 필드는 4바이트, 두 번째 필드는 10바이트..." 식의 길이 정보나 순서를 미리 명시

2) 분리 특수 문자 (Separator/Delimiter) 활용

• 필드와 필드 사이에 약속된 특수 문자(Marker)를 끼워 넣는다.
• 예시:
  • CSV 파일: 쉼표(,)로 구분.
  • 스크립트 예시: 세미콜론(;)이나 슬래시(/) 등을 사용.
  • 웹/데이터 통신: XML/JSON처럼 태그(<Tag>...</Tag>)나 괄호{}를 사용하여 "여기서 시작해서 여기서 끝난다"를 명확히 함.

 

[ 버퍼링(Buffering) ]

1. 버퍼링 (Buffering): I/O 횟수 줄이기

디스크는 기계적인 장치(HDD)거나 외부 장치(SSD)이기 때문에, CPU나 메모리에 비해 속도가 현저히 느립니다. 따라서 작은 데이터를 여러 번 쓰는 것보다, 모아서 한 번에 쓰는 것이 훨씬 효율적이다.

 

예시 코드

// 상황: fd(파일)에 데이터를 기록함
// 현재 버퍼 상태: [ 1 2 3 4 ]

write(fd, "5678", 4); // 4바이트 쓰기
write(fd, "ABCD", 4); // 4바이트 쓰기

• 버퍼링이 없는 경우 (Unbuffered I/O):
  1. 1234 쓰기 위해 디스크 접근 (모터 회전, 헤드 이동) → 1회
  2. 5678 쓰기 위해 디스크 접근 → 1회
  3. ABCD 쓰기 위해 디스크 접근 → 1회

결과: 총 12바이트를 쓰는데 3번의 디스크 I/O 발생. (매우 비효율적)

 

• 버퍼링을 하는 경우 (Buffered I/O):
  1. 1234, 5678, ABCD를 운영체제 커널의 메모리 버퍼(Buffer)에 차곡차곡 쌓음. (디스크 접근 X)
  2. 버퍼가 꽉 차거나 flush 명령이 떨어지면, 한 방에 디스크로 전송
  3. 결과: 총 12바이트를 쓰는데 단 1번의 디스크 I/O 발생 (성능 대폭 향상)

• 이중 버퍼링 (Double Buffering): 버퍼 하나가 디스크에 기록(Flush)되는 동안, CPU는 놀지 않고 두 번째 버퍼에 다음 데이터를 채우는 방식. (병렬 처리로 효율 극대화)

---

2. 저장 장치의 물리적 특성과 성능

버퍼링이 필요한 근본적인 이유는 저장 장치의 물리적 한계 때문

① 하드디스크 (HDD)

 

• 구조: 플래터(원판)를 모터로 회전시키고, 액추에이터 암(Arm)이 움직여 데이터를 읽음
• 성능 요소:
  • RPM (분당 회전수): 5400, 7200 RPM 등. 빠를수록 좋지만 물리적 한계가 명확함
  • 하드웨어 버퍼(Cache): HDD 자체에도 64MB~512MB 정도의 메모리를 내장하여 속도 차이를 완충함
• 한계: 데이터를 찾기 위해 물리적으로 헤드가 움직여야 하므로 랜덤 I/O(여기저기 흩어진 데이터 읽기) 성능이 매우 떨어짐

 

② SSD (NAND Flash 기반)

 

• 구조: 모터 없이 반도체(NAND Flash)로 구성. 메모리처럼 전기적으로 접근
• 성능: HDD보다 월등히 빠르며, 특히 랜덤 I/O 속도가 압도적임
• 특징:
  • IOPS (초당 입출력 횟수): HDD와 비교할 수 없을 정도로 높음
  • 수명: 쓰기/삭제(Erase) 횟수에 제한이 있어 수명 관리가 필요(Wear Leveling)

 

---

3. 또 다른 최적화 기법들

운영체제와 하드웨어는 버퍼링 외에도 속도를 높이기 위해 다음과 같은 기술을 사용한다.

1. 미리 읽기 (Read Ahead):
   • 원리: 사용자가 "1번 섹터"를 요청하면, 디스크는 "곧 2, 3, 4번도 읽겠지?"라고 예측하고 주변 섹터까지 미리 읽어서 버퍼에 넣어둠
   • 근거: 공간 지역성(Spatial Locality) 원리 (데이터는 보통 연속해서 저장되므로)
2. 디스크 스케줄링 (Elevator Algorithm):
   • 원리: 버퍼에 쌓인 쓰기 요청들의 순서를 재조정하여, 헤드의 이동 거리를 최소화함. (1층 갔다가 10층 갔다가 다시 2층 가는 비효율 방지)

 

14주차

[ 논리적 구조 ]

• 평면 디렉터리 구조
  • 파일 시스템 전체에 하나의 디렉터리만 존재하고 모든 파일들을 이 하나의 디렉터리에 저장하는 구조 (서브 디렉터리의 개념이 없는 구조)
  • 단일 사용자 환경의 경우 시스템 파일들과 사용자 파일들이 모두 한 디렉터리에 존재해야 하므로 이들의 이름을 모두 다르게 구성해야 함 (유일성 보장 필요)
  • 초기에는 파일명 길이에 제약(예: 8Byte)이 있었으나, 저장 용량이 작아 큰 문제는 아니었다.

 

• 2단계 디렉터리 구조 (평면 구조를 확장)
  • 다중사용자 기반의 평면 디렉터리 구조 보완
  • 중앙 디렉터리(MFD: Master File Directory) 아래에 사용자별 디렉터리(UFD: User File Directory)가 존재하는 2단계 구조 (최상위 디렉터리에 사용자별로 존재)
  • 각 사용자마다 디렉터리를 하나씩 배정 (다른 사용자 디렉터리에 동일한 파일명을 허용)

 

 

• 계층 디렉터리 구조 (2단계 디렉터리 구조를 보완)
  • 사용자들로 하여금 자신의 파일들을 나름대로의 기준으로 분류하여 별도의 디렉터리에 유지할 수 있는 구조
  • 대부분의 현대 운영체제가 갖는 디렉터리 구조 (UNIX/Linux, Windows, MS-DOS 등)
  • 최상위 디렉터리를 root로 표현하며, 계층적인 하부 디렉터리 생성 가능

Root → bin → mail (서브 디렉터리) → copy (실제 파일) 순으로 탐색

 

• 그래프 디렉터리 구조 (계층 디렉터리 구조의 확장)
  • Acyclic Graph, General Graph 두 가지 유형으로 구분 (순환의 차이)
  • 사용자들이 공유하고자 하는 파일들을 하나의 디렉터리 또는 일부 서브 디렉터리에 저장해 놓고 여러 사용자들의 공유가 가능하도록 디렉터리를 연결하는 방식
  • 현대 파일시스템에서는 순환참조를 허용 (리눅스에서 많이 사용)

 

• 비순환 그래프 (Acyclic Graph): 공유는 허용하되, 사이클(Cycle, 순환)은 허용하지 않음
• 일반 그래프 (General Graph): 순환 참조(Cycle)까지 허용함

 

Acyclic Graph,  General Graph

 

[ 윈도우 : FAT 파일 시스템의 구조 및 특징 ]

FAT12 - FAT16 -FAT 32 순으로 개선됨

• FAT 뒤의 숫자: 클러스터의 인덱스를 표현하는 비트(Bit) 수를 의미
• 클러스터(Cluster): 하드디스크의 물리적 최소 단위인 섹터(Sector, 512Byte)는 너무 작아서 관리가 비효율적이다.
  따라서 여러 섹터를 묶어 논리적인 관리 단위(블록)로 만든 것이 클러스터다.

뒤의 숫자로 클러스터의 인덱스를 구성 2^12개만큼 구성할 때 : 4096개 클러스터 구성 가능 (최대 용량)

 

• FAT 16
  • 클러스터 bit가 기존 12bit에서 16bit로 늘어남. 2^16개의 클러스터 표현 가능 (숫자는 클러스터의 비트수를 나타내는 값)
  • 클러스터의 크기가 32KB인 경우 : block을 대치하는 단위 - 클러스터도 유사한 개념
  • 섹터 size : 512Byte, 단위가 작으니까 연산 횟수가 급격히 늘어남 → 이 단위를 묶어서 클러스터로 관리

2^16개 인덱스 구성 = 65536 x 32KB(2^5 x 2^10) = 최대 용량 2GB (총 2^31 = 2 x 2^30(GB))

 

• FAT 32
  • 클러스터 bit 수를 32bit로 확장, 최상위 4bit 예약, 2^28개 클러스터 지원
  • 클러스트의 크기가 16KB인 경우 디스크 용량은 이론상 최대 4TB

 

• FAT16/FAT32 파일시스템 구조
  •  File Allocation Table (4Byte씩 할당, 각 바이트가 한 클러스터에 대한 정보를 담음)

File Allocation Table

 

0번(Media Type), 1번(Partition Status) 클러스터는 특수한 목적(고정된 값)으로 사용된다.

0번(Media Type) : 디스크의 종류를 식별하기 위한 고정된 값으로 사용

1번(Partition Status) : 파티션 상태 정보확인을 위해 사용

2번부터 실제 파일 데이터가 저장된 클러스터 정보를 담음

 

클러스터의 개수가 늘어날수록이 File Allocation Table의 크기가 커지게 됨

4Byte(디스크의 공간) x 클러스트 개수로 테이블을 구성

 

하나의 파일에 대한 클러스터인지, 하나의 파일에 대한 다수의 클러스터들인지, 아직 사용 중이지 않은 비어 있는 공간인지, 사용할 수 없는 클러스터인지를 알 수 있음

 

클러스터의 개수가 많아질수록 FAT의 크기도 증가 → 탐색 시간이 증가

 

[ 파일시스템 : EXT (리눅스) ]

• 1987년 Andrew S. Tanenbaum 교수에 의해 Minix 개발 -> Minix FS
• 1992년 4월 Linux 0.96c 버전 커널에 VFS가 통합되고, Minix FS를 개선한 Ext 파일시스템 추가
  • 최대 2TB 저장 가능, 단일 파일의 최대 크기는 2GB
  • 최대 파일명은 255byte
• 1993년 1월 Ext 파일시스템의 단점을 보완하기 위해 XIA와 Ext2 파일시스템 개발
  • 파일시스템의 최대 크기는 4TB, 단일 파일의 최대 크기는 2GB

 

[ EXT 파일시스템의 블록 관리 및 최대 파일 크기 ]

FAT와 다르게 EXT는 인덱스의 개수(포인터)가 15개로 고정되어 있어, 대용량 파일에서도 일정한 접근 속도를 보장함. (FAT의 순차 탐색 속도 저하 문제 해결)

FAT는 연결 리스트(Linked List) 방식이라 순차 탐색을 해야 해서 느린 반면, EXT는 인덱스(Index) 방식이라 바로 접근이 가능

 

전제 조건

• 블록 크기: 1KB (1,024 바이트)
• 블록 개수: 직접 블록 12, 단일 1, 이중 1, 삼중 1
• 블록 주소 크기: 4Byte (32비트)로 가정 (일반적인 표준)
• 블록 당 주소(인덱스) 개수: 1,024Byte / 4 Byte = 256개 슬롯, 즉, 간접 블록 하나는 256개의 데이터 블록을 가리킬 수 있음

단계 (Level)	구조 (Path)	계산 식 (인덱스 수 × 블록 크기)	용량 (Capacity)
① 직접 블록 (Direct)	i-node → 데이터 블록 아이노드가 파일 데이터가 담긴 블록을 직접 가리킴	12개 x 1KB	12 KB
② 단일 간접 (Single Indirect)	i-node → 주소 → 데이터 블록 13번째 포인터는 주소가 담긴 블록을 가리키고, 이 주소 블록이 다시 256개의 데이터 블록을 가리킴	256개 x 1KB	256 KB
③ 이중 간접 (Double Indirect)	i-node → 주소 → 주소 → 데이터 블록 14번째 포인터는 주소 블록을, 그 안의 주소들은 또 다른 주소 블록들을 가리킴	256 x 256 x 1KB	65,536 KB = 64 MB
④ 삼중 간접 (Triple Indirect)	i-node → 주소 → 주소 → 주소 → 데이터 블록 15번째 포인터, 이중 간접 방식이 한 단계 더 확장된 구조	256 x 256 x 256 x 1KB	16,777,216 KB = 16 GB

간접 블록(데이터를 저장 x, 인덱스 저장용) : 블록의 인덱스 크기가 4Byte라 가정 (1KB의 블록을 4byte 크기의 인덱스를 담을 수 있는 슬롯으로 쪼개야 함) → 1KB /4Byte = 256개의 슬롯

 

12KB + 256KB + 64MB + 16GB ≅ 약 16.06GB

---

1KB → 4KB로 용량이 바뀐다면?

• 블록 크기: 4KB (4,096 바이트)
• 블록 주소 크기: 4바이트 (32비트)로 동일하게 가정
• 블록 당 주소 개수: 4,096 바이트 / 4 바이트 = 1,024개 (기존 256개에서 4배 증가) → 즉 1024개의 슬롯

최대 파일 크기 재계산

1. 직접 블록 (Direct Blocks)

• 계산: 12개 (포인터) × 4KB (블록 크기) = 48KB

2. 단일 간접 블록 (Single Indirect Block)

• 계산: 1,024개 (주소) × 4KB (블록 크기) = 4,096KB = 4MB

3. 이중 간접 블록 (Double Indirect Block)

• 계산: 1,024 × 1,024 (주소) × 4KB (블록 크기) = 4,194,304KB = 4GB

4. 삼중 간접 블록 (Triple Indirect Block)

• 계산: 1,024 × 1,024 × 1,024 (주소) × 4KB (블록 크기) = 4,294,967,296KB = 4TB

총합은 약 4TB