floatFirstTOC: right
🖥️ 시작하며🔍 Basic Concepts📌 File💡 Files 예시📌 File System💡 Files vs File Systems📌 저장소의 논리적 뷰🔍 File과 File Systems📌 File의 구조📌 File Systems⚙️ File Systems의 목표🔍 Directories📌 Hierarchical Directory System (계층적 디렉토리 시스템)📌 Directory Internals1️⃣ 디렉터리의 정의2️⃣ 디렉터리의 구성 요소3️⃣ 디렉터리의 정렬📌 Pathname Translation💡 예시: ‘open(”/a/b/c”, …)”⚙️ 디렉터리 경로 탐색의 비효율성⚙️ 성능 향상을 위한 OS 캐시📌 Directory Operations🔍 Mounting1️⃣ Windows에서의 마운트2️⃣ Unix에서의 마운트🔍 File Sharing💡 파일 공유 시 고려해야 할 세 가지 주요 문제📌 Consistency Semantics1️⃣ Unix2️⃣ AFS session (요즈음 사용)3️⃣ Immutable-Shared-Files📌 File Locking1️⃣ Advisory Lock 2️⃣ POSIX record Lock🔍 Protection📌 Protection Systems1️⃣ 기본 요소2️⃣ 일반화된 요소3️⃣ 보호 시스템의 역할📌 Representing Protection1️⃣ 접근 제어 리스트 (Access Control Lists, ACLs)2️⃣ 권한 (Capabilities)접근 제어 리스트 (ACLs)와 권한 (Capabilities)의 차이점
🖥️ 시작하며
운영체제에서의 파일 시스템에 대해 알아봅니다.
🔍 Basic Concepts
- 장기 정보를 저장하기 위해서는 아래와 같은 요구사항이 필요:
- 매우 큰 양의 정보를 저장할 수 있어야 함
- 이용 중인 프로세스가 종료되더라도 정보가 보존되어야 함
- 다수의 프로세스가 동시에 정보에 접근할 수 있어야 함
📌 File
2차 저장소에 기록된 데이터의 집합
- 파일은 서로 연관된 정보의 이름 붙여진 컬렉션
- 일반적으로 확장자는 포함되지 않음
- 운영체제는 파일을 통해서 저장된 정보의 통일된 Logical한 View 제공
💡 Files 예시
- 텍스트 파일 (example.txt)
- 관련된 데이터: "Hello, World!"라는 문자가 저장되어 있음
- 명명된: "example.txt"
- 콜렉션: "H", "e", "l", "l", "o", ",", " ", "W", "o", "r", "l", "d", "!"라는 문자들이 모여서 만들어진 컬렉션
- 이미지 파일 (picture.jpg)
- 관련된 데이터: 이미지의 픽셀 데이터가 저장됨
- 명명된: "picture.jpg"
- 콜렉션: 각 픽셀이 RGB 값을 가진 데이터의 모음으로 구성된 컬렉션
📌 File System
2차 저장소에 기록된 추상화된 파일을 구현
- 디렉토리: 파일을 논리적으로 조직화
- 프로세스, 사람, 기계 간 데이터 공유 허용
- 원치 않는 접근으로부터 데이터 보호
💡 Files vs File Systems
항목 | 파일 (File) | 파일 시스템 (File System) |
정의 | 관련된 데이터를 저장한 명명된 컬렉션 | 파일을 조직, 저장 및 관리하기 위한 시스템 소프트웨어 |
역할 | 데이터를 저장하고 식별할 수 있도록 이름을 부여 | 파일을 저장 장치에 효율적으로 저장, 조직, 접근, 보호하는 기능 제공 |
구성 요소 | 데이터의 논리적 블록, 메타데이터 (파일 이름, 크기, 생성 날짜 등) | 파일과 디렉터리 구조, 파일 할당 테이블, 저널, 인덱스 등 |
저장 위치 | 2차 저장 장치 (하드 디스크, SSD 등) | 2차 저장 장치에 구현됨 |
접근 방법 | 파일 이름과 경로를 통해 접근 | 운영 체제의 시스템 호출 인터페이스를 통해 접근 (예: open(), read(), write(), close() 등) |
지속성 | 전원 실패 및 시스템 재부팅 후에도 지속성 유지 | 파일의 지속성을 보장하고 파일 시스템의 무결성을 유지하기 위해 저널링, 체크섬, 백업 등 사용 |
관리 단위 | 개별 파일 | 파일 및 디렉터리 전체 |
보안 및 권한 | 파일 수준에서 접근 권한 설정 (읽기, 쓰기, 실행 등) | 파일 및 디렉터리 수준에서 접근 제어 및 보안 정책 적용 (ACL, 사용자/그룹 권한 등) |
동시 접근 | 여러 프로세스가 동시에 파일을 접근할 수 있으며, 파일 잠금 메커니즘 필요 | 다수의 프로세스가 파일 시스템을 동시에 접근 가능하게 하며, 이를 위한 동기화 및 파일 잠금 메커니즘 제공 |
데이터 구조 | 바이너리 또는 텍스트 형식의 데이터 블록 | 데이터 블록, 메타데이터 블록, 인덱스 블록, 디렉터리 엔트리 등 |
기능 | 데이터 저장, 읽기, 쓰기, 수정 | 파일 생성, 삭제, 읽기, 쓰기, 수정, 파일 및 디렉터리 조직, 디스크 공간 할당 및 해제, 파일 시스템 무결성 검사 및 복구 기능 |
예시 | 텍스트 파일, 이미지 파일, 실행 파일 등 | NTFS, ext4, APFS, FAT32 등 |
사용자 인터페이스 | 파일 이름, 경로, 확장자 등을 통해 사용자에게 노출 | 파일 시스템 인터페이스는 운영 체제와 상호 작용하며, 사용자는 파일 탐색기나 명령 줄 인터페이스를 통해 파일 시스템과 상호작용 |
메타데이터 관리 | 파일 크기, 생성 및 수정 날짜, 권한 정보 등 포함 | 파일 시스템은 파일의 메타데이터를 관리하고, 이를 통해 파일 검색 및 접근을 효율화 |
장치 독립성 | 저장 장치에 관계없이 동일한 방식으로 파일 접근 가능 | 파일 시스템은 다양한 저장 장치에서 작동하며, 장치의 물리적 특성을 추상화하여 동일한 인터페이스 제공 |
복구 기능 | 개별 파일 수준에서의 복구 기능 제공 (예: 백업에서 복원) | 파일 시스템은 저널링, 스냅샷, 복구 도구 등을 통해 시스템 장애 후에도 데이터 복구 가능 |
📌 저장소의 논리적 뷰
- 블록 단위 저장소
- 저장소는 512B 크기의 블록 단위로 나누어져 있음
- 블록 번호
- 각 블록은 고유한 번호를 가짐
- Read, Write 연산이 존재 (X부터 Y만큼의 데이터)
🔍 File과 File Systems
📌 File의 구조
- 파일 이름
- 파일 속성 (File attributes, metadata)
- 파일 크기 (File size): 파일의 총 크기를 바이트 단위로 나타냄
- 소유자, 접근 제어 목록 (Owner, access control lists): 파일의 소유자 정보와 접근 권한을 설정
- 생성 시간 (Creation time)
- 마지막 접근 시간 (Last access time)
- 마지막 수정 시간 (Last modification time)
- 파일 내용 (File contents, data)
- 파일에 저장된 실제 데이터, 파일 시스템은 보통 이 데이터의 내용에 대해 신경 쓰지 않음
→ 데이터가 텍스트인지, 이미지인지, 실행 파일인지 중요하지 않음
📌 File Systems
파일 시스템은 파일의 구조를 Mapping하는 문제
⚙️ File Systems의 목표
결국 성능 + 신뢰성을 모두 만족해야 함
- 메타데이터에 어떤 정보를 포함할 것인가?
- 파일 크기: 파일의 총 크기 (바이트 단위).
- 소유자 정보: 파일 소유자와 그룹.
- 접근 권한: 읽기, 쓰기, 실행 권한.
- 시간 정보: 파일 생성 시간, 마지막 수정 시간, 마지막 접근 시간.
- 파일 유형: 일반 파일, 디렉터리, 링크 등.
- 블록 위치 정보: 파일 데이터가 저장된 블록 위치 정보.
- 메타데이터를 어떻게 위치시킬 것인가?
- 파일 이름 경로에서 메타데이터로의 매핑
- 디렉터리 구조를 통해 파일 이름을 사용하여 해당 파일의 메타데이터를 찾음
예를 들어,
inode
번호를 사용하여 메타데이터를 찾는 방식이 존재- 데이터 블록을 어떻게 찾을 것인가?
- 메타데이터 (예:
inode
)는 파일의 데이터 블록 목록을 포함하고 있음, 이를 통해 데이터 블록의 물리적 위치를 찾음
- 메타데이터와 데이터 블록을 어떻게 관리할 것인가?
- 할당 (Allocation): 새로운 파일을 위한 블록 할당.
- 회수 (Reclamation): 파일이 삭제되었을 때 블록 회수.
- 여유 공간 관리 (Free space management): 파일 시스템의 사용 가능한 블록을 추적하고 관리.
- 충돌 후 파일 시스템을 어떻게 복구할 것인가?
- 메타데이터가 날라가면 다른 데이터도 찾지 못함
- 저널링 (Journaling): 변경 사항을 기록하여 충돌 후 복구할 수 있도록 함
- 스냅샷 (Snapshots): 특정 시점의 파일 시스템 상태를 저장하여 복구에 사용
- 체크섬 (Checksums): 데이터 무결성을 확인하고 손상된 데이터를 감지
🔍 Directories
- 유저 입장에서:
- 파일을 찾을 수 있는 구조화된 방법을 제공
- 파일 시스템 관점에서:
- 편리한 명명 인터페이스 제공
- 논리적 파일 조직을 물리적 디스크 배치와 분리해서 구현
📌 Hierarchical Directory System (계층적 디렉토리 시스템)
- 다수의 파일 시스템은 다중 레벨 디렉터리를 지원
- 디렉터리는 트리 구조를 가지며, 각 디렉터리는 다른 디렉터리나 파일을 포함할 수 있음
- 대부분의 파일 시스템은 현재 디렉터리 (또는 작업 디렉터리)의 개념을 지원
- 상대 경로 (Relative Path):
- 현재 디렉터리를 기준으로 한 경로
- 예:
cd ../../../foo/bar/../bar
- 현재 디렉터리에서 상위 디렉터리로 세 번 이동한 후, foo 디렉터리로 이동하고 bar로 다시 이동
- 절대 경로 (Absolute Path):
- 디렉터리 트리의 루트에서 시작하는 경로
- 예:
cd /tmp/foo/bar
- 루트 디렉터리(/)에서 시작하여 tmp, foo, bar 디렉터리로 차례로 이동하는 경로
📌 Directory Internals
1️⃣ 디렉터리의 정의
- 디렉터리는 일반적으로 특수한 메타데이터를 포함한 파일
- 디렉터리는 (파일 이름, 파일 속성)의 목록으로 구성됨
2️⃣ 디렉터리의 구성 요소
- 파일 이름 (File name): 디렉터리 내의 파일을 식별합
- 파일 속성 (File attributes): 다음과 같은 정보를 포함:
- 크기 (Size)
- 보호 (Protection)
- 생성 시간 (Creation time)
- 접근 시간 (Access time)
- 디스크 상의 위치 (Location on disk): 파일의 데이터 블록이 저장된 물리적 위치 등
3️⃣ 디렉터리의 정렬
- 디렉터리 항목은 보통 정렬되지 않는다. (성능 향상을 위해)
- 디렉터리 항목은 디렉터리를 읽는 프로그램에 의해 정렬되는 경우가 많음
📌 Pathname Translation
💡 예시: ‘open(”/a/b/c”, …)”
- "/" 디렉터리 열기
- "/"는 잘 알려진 루트 디렉터리로, 항상 찾을 수 있습니다.
- 루트 디렉터리를 엽니다.
- "a"를 검색
- 루트 디렉터리에서 "a" 항목을 검색합니다.
- "a"의 위치를 얻습니다.
- "a" 디렉터리 열기 및 "b" 검색
- "a" 디렉터리를 열고, 그 안에서 "b" 항목을 검색합니다.
- "b"의 위치를 얻습니다.
- "b" 디렉터리 열기 및 "c" 검색
- "b" 디렉터리를 열고, 그 안에서 "c" 항목을 검색합니다.
- "c"의 위치를 얻습니다.
- 파일 "c" 열기
- "c" 파일을 엽니다.
- 각 단계에서 권한이 확인됩니다.
⚙️ 디렉터리 경로 탐색의 비효율성
- 시스템은 디렉터리 경로를 따라 내려가느라 많은 시간을 소비
- 이러한 이유로
open()
함수는read()/write()
함수와 분리되어 있음 - 예:
read("/a/b/c", buf, 100);
와 같이 사용되지 않음
⚙️ 성능 향상을 위한 OS 캐시
- 운영 체제는 경로 탐색(prefix lookups)을 캐싱하여 성능을 향상시킴
- 예를 들어,
/a/b
,/a/bb
,/a/bbb
등의 경로를 캐시 - 이들은 모두 "/a" 접두사를 공유
📌 Directory Operations
정리
- 디렉터리의 파일로서의 구현
- 디렉터리는 실제로 파일로 구현됨 (다른 목록을 가지는 파일)
- 파일 작업을 사용하여 디렉터리를 조작합니다.
- C 런타임 라이브러리의 디렉터리 읽기 고수준 추상화
- 디렉터리를 읽기 위한 고수준의 추상화를 제공합니다.
- 주요 함수:
DIR *opendir(const char *name);
- 지정된 이름의 디렉터리를 열고
DIR
포인터를 반환합니다. struct dirent *readdir(DIR *dir);
- 열린 디렉터리에서 다음 항목을 읽고
dirent
구조체 포인터를 반환합니다. void seekdir(DIR *dir, off_t offset);
- 열린 디렉터리에서 읽기 위치를 지정된 오프셋으로 이동합니다.
int closedir(DIR *dir);
- 열린 디렉터리를 닫습니다.
- 기타 디렉터리 관련 시스템 호출
- 디렉터리 및 파일에 대한 다양한 시스템 호출을 제공합니다.
int rename(const char *oldpath, const char *newpath);
- 파일 또는 디렉터리의 이름을 변경합니다.
int link(const char *oldpath, const char *newpath);
- 파일에 대한 하드 링크를 생성합니다.
int unlink(const char *pathname);
- 파일을 삭제합니다
🔍 Mounting
파일 시스템은 프로세스에서 사용할 수 있도록 마운트되어야 함
- 마운트는 특정 위치에 파일 시스템을 연결해 시스템의 일부로 만들고, 해당 위치에서 파일 시스템에 접근할 수 있도록 함
1️⃣ Windows에서의 마운트
- 드라이브 문자에 파일 시스템을 마운트
- 예:
C:\
,D:\
등 - 각 드라이브 문자는 특정 파일 시스템을 나타내며, 사용자는 드라이브 문자를 통해 파일 시스템에 접근
2️⃣ Unix에서의 마운트
- 기존의 빈 디렉터리에 파일 시스템을 마운트
- 이 디렉터리를 마운트 포인트 (mount point)
- 예:
/mnt
,/media
,/home
등의 디렉터리에 파일 시스템을 마운트할 수 있음 - 마운트 포인트가 되기 위해서는 디렉터리가 비어 있어야 함
🔍 File Sharing
- 파일 공유는 timesharing 시대부터 존재
- 작업을 완료하기 위해 매우 중요하며, 커뮤니케이션과 동기화의 베이스가 됨
💡 파일 공유 시 고려해야 할 세 가지 주요 문제
- 동시 접근의 의미 (Semantics of concurrent access)
- 동시 읽기/쓰기 문제
- 한 프로세스가 파일을 읽는 동안 다른 프로세스가 파일을 쓰는 경우 어떻게 될까?
- 동시 쓰기 문제
- 두 프로세스가 동시에 파일을 쓰기 위해 열 때 어떻게 될까?
→ 일반적으로 데이터의 무결성을 보장하기 위해 일관성 모델이 필요
→ 데이터 경합(race condition)과 데이터 손상(data corruption)을 방지하기 위한 적절한 메커니즘이 필요
- 동시성 제어 (Concurrency control)
- 파일 잠금 (Locks)
- 파일 잠금 메커니즘을 사용하여 동시 접근을 제어
- 공유 잠금 (Shared lock): 여러 프로세스가 동시에 파일을 읽을 수 있지만 쓸 수는 없음
- 배타적 잠금 (Exclusive lock): 하나의 프로세스만 파일을 읽거나 쓸 수 있음
- 잠금 메커니즘은 동시 접근 문제를 해결하여 데이터의 무결성을 유지
- 보호 (Protection)
- 접근 제어
- 파일에 대한 접근 권한을 설정하여 특정 사용자나 그룹만 파일을 읽거나 쓸 수 있도록 함
- 예: 읽기, 쓰기, 실행 권한 설정
📌 Consistency Semantics
1️⃣ Unix
- 열린 파일에 대한 쓰기 작업은 해당 파일을 동시에 열고 있는 다른 사용자에게 즉시 반영
2️⃣ AFS session (요즈음 사용)
- Andrew File System (AFS)은 분산 파일 시스템의 일종
- 열린 파일에 대한 쓰기 작업은 즉시 반영 X
→ 파일이 닫혀야 다른 사용자에게 보임
3️⃣ Immutable-Shared-Files
- 파일이 생성자에 의해 공유로 선언되면 더이상 수정 불가능
📌 File Locking
1️⃣ Advisory Lock
프로그램이 자발적으로 따르는 잠금 메커니즘
시스템 차원에서 적용되는 게 아닌 파일에 접근하는 프로그램이 잠금 상태를 확인
- 함수:
int flock (int fd, int operation);
- 매개변수:
fd
: 파일 디스크립터operation
: 잠금 작업의 종류LOCK_SH
(shared): 공유 잠금- 여러 프로세스가 동시에 읽을 수 있도록 허용하지만, 쓰기는 불가능
LOCK_EX
(exclusive): 배타적 잠금LOCK_UN
(unlock): 잠금 해제
2️⃣ POSIX record Lock
파일의 특정 부분만 잠금 가능
프로세스가 종료되면 해당 프로세스의 잠금이 해제
- 함수:
int fcntl (int fd, int cmd, struct flock *lock);
- 매개변수:
fd
: 파일 디스크립터cmd
: 명령어F_GETLK
: 잠금 상태 조회F_SETLK
: 잠금 설정F_SETLKW
: 잠금 설정, 잠금이 해제될 때까지 대기lock
:struct flock
구조체 포인터로, 잠금의 세부 정보를 포함
- 구조체:
struct flock
- 구성 요소:
type
: 잠금 유형F_RDLCK
: 읽기 잠금F_WRLCK
: 쓰기 잠금F_UNLCK
: 잠금 해제whence
: 시작 오프셋 기준점 (SEEK_SET
,SEEK_CUR
,SEEK_END
)start
: 파일 내에서 잠금을 시작할 오프셋len
: 잠금을 적용할 길이 (바이트 단위)pid
: 잠금을 설정한 프로세스의 PID
🔍 Protection
파일 시스템은 파일에 대한 접근을 제어하기 위해 보호 시스템 구현
📌 Protection Systems
1️⃣ 기본 요소
- 사용자 (User)
- 파일에 접근하려는 주체 (특정 사용자 또는 사용자 그룹)
- 접근 방법 (Access)
- 파일에 대해 어떤 작업을 할 수 있는지 (읽기(read), 쓰기(write), 실행(exec) 등)
2️⃣ 일반화된 요소
- 객체 (Object)
- 보호 시스템에서 보호되는 대상
→ 파일뿐만 아니라, 디렉터리, 데이터베이스 항목, 네트워크 리소스 등 다양한 대상이 포함
- 주체 (Subject)
- 객체에 접근하려는 주체 (사용자, 프로세스, 또는 시스템 자체)
- 행동 (Action)
- 주체가 객체에 대해 수행하려는 작업 (읽기, 쓰기, 실행, 삭제 등)
3️⃣ 보호 시스템의 역할
- 사용자는 자신의 파일을 읽고 쓸 수 있지만, 다른 사용자는 접근할 수 없음
- 모든 사용자가
/etc/passwd
파일을 읽을 수 있지만, 수정할 수는 없음
📌 Representing Protection
1️⃣ 접근 제어 리스트 (Access Control Lists, ACLs)
각 객체(object)에 대해 접근 권한을 가진 주체(subject)와 허용된 행동(action)을 목록으로 유지
2️⃣ 권한 (Capabilities)
각 주체(subject)에 대해 접근 가능한 객체(object)와 허용된 행동(action)을 목록으로 유지
접근 제어 리스트 (ACLs)와 권한 (Capabilities)의 차이점
특징 | 접근 제어 리스트 (ACLs) | 권한 (Capabilities) |
정의 | 각 객체에 대해 접근 권한을 가진 주체와 허용된 행동을 목록으로 유지 | 각 주체에 대해 접근 가능한 객체와 허용된 행동을 목록으로 유지 |
구성 요소 | 객체별로 주체와 행동의 목록 | 주체별로 객체와 행동의 목록 |
관리 기준 | 객체 중심 | 주체 중심 |
접근 권한 확인 | 특정 객체에 대한 접근 권한을 쉽게 확인 | 특정 주체가 접근 가능한 모든 객체를 쉽게 확인 |
장점 | - 상세한 접근 제어 가능 | - 주체별 접근 권한 확인 용이 |
ㅤ | - 객체를 기준으로 접근 권한 관리 용이 | - 객체 수가 많아도 분산 관리로 성능 유리 |
단점 | - 많은 객체의 경우 관리 복잡 | - 많은 주체의 경우 관리 복잡 |
ㅤ | - 시스템 성능에 영향 | - 객체 중심의 접근 권한 확인 어려움 |
사용 시나리오 | 파일 시스템, 데이터베이스, 네트워크 리소스 관리 | 사용자 인증 및 권한 관리, 분산 시스템 |
일관성 유지 | 주체가 많을 경우 일관성 유지 어려움 | 객체가 많을 경우 일관성 유지 어려움 |
성능 영향 | 주체와 객체의 수에 따라 성능 저하 가능 | 객체가 많을 경우 성능 저하 가능 |
일반적인 사용 사례 | - 파일 시스템에서 파일과 디렉터리의 접근 권한 관리 | - 분산 시스템에서 사용자 권한 관리 |
ㅤ | - 네트워크 리소스에 대한 접근 제어 | - 객체 기반의 접근 제어가 필요한 환경 |
추가적인 관리 편의 | - 그룹을 사용하여 관리 단순화 가능 | - 권한을 개별 주체에게 쉽게 전달 가능 |
ㅤ | - 그룹 멤버십 변경 시 ACL에 해당 그룹이 포함된 모든 객체에 즉시 반영 | ㅤ |
댓글