[OS] Files and Directory

3년간 산업기능요원으로 복무 하고, 복학해 컴공과 수업을 듣고 있습니다. 그동안 많이 배웠다고 생각했는데, 여전히 부족한 부분이 많네요 ^^;; 역시 세상도 넓고 공부의 길도 넓은 것 같습니다.

들어가며

요 포스트는 운영체제를 공부하면서 짧게 메모 했던 것들을 모은 글 입니다. OS 내용을 복습하면서 살펴보면 좋을 것 같습니다 🙂

Sector vs. Block

[Sector]

• 디스크의 최소 “물리적 저장 단위”
• 일반적으로 512 bytes 또는 4 kb
• 디스크에 데이터를 저장할 때, 섹터 단위로 읽거 쓰기 작업을 함.

[Block]

• 파일 시스템에서 데이터를 관리하는 “논리적 단위”
• 여러 섹터를 합쳐서 구성됨. 보통 4 kb 또는 8 kb 또는 그 이상

파일 시스템이 데이터를 디스크에 저장할 때는 섹터 단위가 아니라 블록 단위로 이뤄짐. 작은 단위로 여러 번 읽는 것보다 큰 단위(블록)으로 한 번에 R/W 하는게 더 효율적이기 때문.

Data Structures for File System

13p 그림

• Process Control Block
  • 각 프로세스의 PCB에서 현재 열고 있는 파일 목록을 관리함.
  • 파일을 열면, 그 기록이 system-wide인 Open File Tables에 기록됨.
  • PCB는 그 내용을 참조할 뿐
• Open File Tables
  • 시스템 전체에 열려 있는 파일들에 대한 정보를 하나의 테이블로 관리
  • 파일이 여러 프로세스에 의해 동시에 열릴 경우, 요 테이블에 한번만 등록되며, 각 프로세스의 테이블은 이 항목을 참고해서 읽음.
• File Descriptors
  • 파일에 대한 메타데이터를 저장
  • 파일 데이터와 별도로 관리하는 것이며, system-wide 테이블이 요 내용을 참조함.
• File System
  • 실제 파일 데이터와 파일 시스템의 정보를 비휘발성 메모리에 저장한 것
  • File Descriptor도 요 내용을 바탕으로 기록 되는 것임.

14p의 그림도 위의 녀석들에 대한 관계를 잘 보여줌!

fopen()이 실행될 떄의 접근 순서는

1. File Descriptors (Metadata)
   1. 요기에서 파일 이름 기준으로 찾고
   2. 유저가 요 파일에 접근할 권한이 있는지 체크함
2. Open File Tables & Process Control Block
   1. 요 테이블들에 등록
3. File System
   1. 파일 데이터에 접근

시스템은 파일 접근을 블록 단위로 처리한다.

[읽기 작업]

• 사용자가 byte offset 2에서 10 bytes 만큼을 읽고 싶다면
• 바이트 오프셋 2의 위치를 찾는다 (seek)
• 해당 바이트가 속한 블록을 가져온다. (fetch the block)
• 블록에서 10 bytes 만큼 읽는다.

파일은 블록 단위로 저장되기 때문에, 조금의 바이트를 읽더라도 블록 전체를 읽어와야 함.

[쓰기 작업]

• 사용자가 byte offset 2에서 10 bytes 만큼을 읽고 싶다면
• 바이트 오프셋 2의 위치를 찾는다 (seek)
• 해당 바이트가 속한 블록을 가져온다. (fetch the block)
• 블록에서 바이트 데이터를 수정한다.
• 변경된 블록을 저장소에 반영한다.

마찬가지로 파일을 블록 단위로 데이터를 다루기 때문에, 바이트 단위의 수정도 블록 전체를 읽고 수정 해야 함.

핵심은 파일 시스템에서는 모든 파일이 블록 단위로 관리된다는 것이고, 논리적 레코드 크기(사용자가 R/W 하는 크기)와 물리적 블록 크기는 다를 수 있다는 점.

이런 방식을 “블록 버퍼링(Block Buffering)“이라고 한다.

파일 시스템 디자인 때 고려할 점

[작은 파일 위주라면]

• 작은 블록을 사용해야 내부 단편화가 적음
• 연관된 파일을 인접 위치에 저장해두는게 좋음.

[큰 파일 위주라면]

• 클 블록을 사용해 디스크 접근 횟수를 줄이는게 좋음.
• 데이터를 연속적으로 할당해 순차 접근을 빠르게 만드는게 좋음.
  • ex. 비디오, 데이터베이스 백업
• 랜덤 접근을 효율적으로 할 수 있도록 Index 구조가 있으면 좋음.

그러나 파일의 크기는 고정된 것이 아니라 동적으로 변하는 것이기 때문에, 파일 생성 때 크기를 예측 할 수 없음. 처음엔 작은 파일로 시작했지만 나중엔 커질 수 있음. (ex. 로그 파일에 로그가 쌓이는 경우) 그리고 파일 접근 패턴도 예측 불가능함.

위의 내용을 파일 크기에 따라 권장되는 디자인 패턴이고, 실제 파일 시스템은 파일의 다양한 특성을 지원할 수 있도록 유연하게 설계 되어야 함.

파일 접근 패턴을 기준으로 보면, 접근 빈도가 높은 파일의 유형은 크기가 작은 파일들임. 그러나, 시스템과 디스크 사이의 I/O 데이터 양을 기준으로 보면 크기가 큰 파일들이 높은 비중을 차지함.

대부분의 파일을 순차적으로 접근하지만, 일부 파일(database file)은 랜덤 접근이 필요함.

Types of File System

• General Purpose FS
  • ufs(Unix File System)
  • zfs(Zettabyte File System)
• Special-purpose FS
  • tmpfs(Temporary File System)
    • 메모리 기반의 휘발성 파일 시스템
    • 빠른 I/O를 제공, 임시 파일 저장에 사용
  • procfs(Process File System)
    • 커널의 프로세스 정보에 접근할 수 있는 인터페이스
    • 현재 실행 중인 프로세스의 상태와 정보를 파일 시스템 형태로 제공함.
    • Linux의 /proc 디렉토리가 요 procfs의 예시임.

Terms

디스크(Disk)는 여러 파티션(Partition)으로 나뉠 수 있음.

디스크나 파티션은 파일 시스템 없이 쓸 수도 있는데, 이 경우 “Raw” 상태라고 함. 만약 파일 시스템과 함께 사용한다면, “Formatted” 상태라고 함.

파티션 중에서 파일 시스템이 포함된, “Formatted” 파티션을 볼륨(Volume)이라고 함. 각 볼륨에는 파일에 대한 정보가 포함된 디렉토리(Directory)가 존재함.

파티션을 기존 디스크를 쪼개서 생성할 수도 있지만, 여러 디스크를 모아허 하나의 파티션으로 만들 수도 있음!

파일 시스템 디자인 고려 사항

• Index Structure
  • 파일의 데이터 블록 위치를 어떻게 찾을 것인지
  • 파일은 여러 블록에 나뉘어 저장될 수 있음. 그래서 파일에 접근할 때, 이 블록들을 효율적으로 추적하고 접근할 수 있어야 함.
• Index Granularity
  • 블록 크기를 어떻게 정할지 결정해야 함.
• Free Space
  • 디스크에서 비어있는 블록을 어떻게 찾고 관리할 것인가
• Locality
  • 파일의 데이터 블록이 인접한 위치에 저장되도록 해야 성능이 좋아짐
• Reliability
  • 파일 시스템 작업 중, 시스템이 중단 되었을 때 데이터 무결성을 보장해야 함.

File Systems

FAT (File Allocation Table)

파일 블록들이 Linked List 형태로 관리됨. 단점은 중간 블록에 접근하기 위해서는 순차 탐색을 해야 함.

여유 공간을 Linked List 기반의 FAT 구조로 관리함.

“Defragmentation”라는 기법으로 조각난 블록들을 재배치 합니다. 이를 통해 지역성을 높입니다.

FFS (Fast File System)

파일 블록을 비대칭 트리 구조로 인덱싱 함. 빠르게 접근이 가능함.

bitmap으로 여유 블록을 관리함.

NTFS (New Technology File System)

파일 블록을 동적 트리 구조로 관리함. 빠르게 접근 가능하고, 대용량 파일에 적합.

여유 공간을 파일 형태의 비트맵으로 관리함.

ZFS (Zettabyte File System)

트리 구조로 파일 블록을 관리하고, Copy-on-Write 기법을 채택함.