PINTOS 6주차 file system

개요

이번 주차에는 file system을 공부했다. 시간이 촉박했다. 목요일부터 화요일로 일주일이 채 안되어 파일시스템 이론 위주로 공부했다. 가상메모리만큼은 아니지만 꽤 흥미로운 주제였다. 우리가 사용하는 파일들이 다양한 메커니즘으로 구현되어있지만 적절한 추상화(abstraction)을 제공해 운영체제가 파일 시스템 각각을 인지하지 않아도 같은 api로 작동하게 만든 점이 인상깊었다. 그리고 파일 시스템이 발전해온 과정을 따라가니 사람들이 어떻게 문제를 해결해왔는지 볼 수 있어서 좋았다.

37 하드 디스크 드라이브

• 파일 시스템을 하드 디스크의 동작 원리에 맞추어 개발할 만큼 중요한 저장장치
• 모든 드라이브는 읽고 쓸 수 있는 많은 수의 섹터(512 바이트 블럭)로 이루어져 있다
• 디스크의 주소 공간: n개의 섹터가 있을 때, 0 ~ n-1 섹터들의 배열
• 디스크 드라이브 제조사는 하나의 512바이트 블럭에 대해 쓰기만 원자적으로 보장

구조

• 플래터(platter): 원형의 표면에 자기적 성질을 변형하여 데이터를 지속, 회전축에 고정되어 회전함
• 트랙(track): 플래터에서 동심원 하나(회전축으로부터 같은 거리에 떨어진 섹터들의 집합)
• 디스크 헤드(disk head): 읽기/ 쓰기 동작을 하는 주체
• 디스크 암(disk arm): 디스크 헤드를 움직이는 주체

I/O 시간

• 전체 시간 = 탐색 시간 + 회전 지연 시간 + 전송 시간

1. 탐색 시간: 디스크 암을 타겟 트랙 위에 위치시키는 시간(가속 - 활주 - 감속 - 안정화 단계로 구성)
2. 회전 지연 시간: 디스크 헤드 아래에 원하는 섹터가 위치하기를 기다리는 시간

RAID(Redundant Array of Inexpensive Disk)

• 여러 개의 하드 디스크를 하나의 하드 디스크처럼 사용하는 시스템
• 성능: 여러 개의 디스크를 병렬로 연결하면 I/O시간이 크게 개선된다
• 용량: 더 많은 디스크로 많은 용량을 저장을 할 수 있다
• 신뢰성: 분산하여 저장해 하나의 디스크 고장에 대응할 수 있다

40 파일 시스템 구현: vsfs(Very Simple File System)

• 파일 시스템은 순수한 소프트웨어: VM/ cpu 가상화와 달리 하드웨어의 도움이 필요하지 않다
• 매우 다양한 파일시스템이 있고, 서로 다른 자료구조를 사용한다

1. 자료구조: 파일 시스템이 자신의 데이터와 메타 데이터를 관리하기 위해 디스크 상에 어떤 자료 구조가 있어야 하는가?
2. 접근방법: 프로세스가 open(), read(), write() 등의 시스템 콜을 호출할 때, 어떤 자료구조가 읽히고 어떤 것들이 쓰이는지, 얼마나 효율적으로 동작하는지?
3. 자료구조, 접근방법 이해 후 실제 동작 방식에 대한 개념 모델 정립 <-- 시스템적 사고 방식의 핵심

vsfs 구성

• 디스크를 블럭(512 바이트)으로 나눈 뒤 다음의 영역들로 구분한다

1. 슈퍼블럭: 파일시스템 전체에 대한 정보(아이노드 블럭 개수, 데이터 블럭 개수, 아이노드 테이블이 어디서 시작하는지 등)
2. 아이노드 비트맵: 아이노드 테이블에 있는 아이노드 사용 여부
3. 데이터 비트맵: 데이터 블럭들의 사용 여부
4. 아이노드 테이블: 아이노드의 저장 공간
5. 데이터 영역: 사용자 데이터가 있는 디스크 공간

아이노드

• 파일의 저수준 이름(low-level name)
• 파일의 메타 데이터를 저장하기위한 자료구조로서, 파일 시스템의 디스크 자료구조 중 가장 중요
• 파일 종류(일반 파일, 디렉토리), 할당 블럭 수, 시간 정보, 파일 크기, 접근 권한, 파일 블럭들의 위치 정보 저장

멀티 레벨 인덱스

• 큰 파일을 지원하기 위해 사용
• 간접 포인터 사용: 간접 포인터가 가리키는 블럭에는 데이터 블럭을 가리키는 포인터들이 저장
• 이중 간접 포인터, 삼중 간접 포인터 등 사용
• 대부분의 파일 크기는 작으므로 작은 파일을 빨리 읽고 쓸 수 있는 파일 구조
• 파일 시스템 소프트웨어는 손쉽게 변경이 가능
• 워크로드 특성의 변화에 따라, 새로운 파일 구성을 연구 개발할 자세가 되어 있어야 함

디렉터리 구조

• (항목 이름, 아이노드 번호) 쌍의 배열로 구성
• "."는 현재 디렉터리, ".."는 부모 디렉터리
• 디렉터리는 특수한 종류의 파일로 간주, 자신의 아이노드를 가지고, 이 아이노드는 아이노드 테이블에 존재

세친구7942님 파일 읽기/ 쓰기 참고

실행 흐름: 파일 읽기

"/foo/bar"를 읽는 과정을 예로 들어보자

• open(bar)

1. "/"(루트) 아이노드에서 루트 디렉토리가 저장된 위치(데이터 블록) 파악(루트 아이노드는 보통 2번)
2. 루트 디럭터리에서 ("foo", inodenum_of_foo)를 찾고 "foo"의 아이노드로 이동
3. "foo"의 아이노드에서 "foo"의 데이터 블록으로 이동
4. "foo"의 디렉터리 데이터에서 ("bar", inodenum_of_bar)쌍을 찾아 "bar"의 아이노드로 이동
5. "bar"의 아이노드를 읽으면 "/foo/bar"를 open()할 수 있음

• read()

6. "bar" 파일을 open했으므로 읽기 수행 가능: "bar"의 아이노드를 읽어 "bar" 데이터 블록으로 이동
7. "bar"의 데이터 읽기
8. "bar"에 접근했으므로 최종 접근 시간을 "bar"의 아이노드에 기록(write)

실행 흐름: 파일 생성

"/foo/bar"를 생성하는 과정을 예로 들어보자

• create(/foo/bar)

1. root 아이노드에서 root 데이터 블록 위치 찾고 이동
2. root 디렉토리의 데이터에서 ("foo", inodenum_of_foo)를 찾고 해당 아이노드로 이동
3. foo 디렉터리의 아이노드에서 foo 디렉터리의 데이터 블록 위치 찾고 이동
4. foo 디렉터리에 파일 bar를 생성하기 위해, 권한 확인 --> 쓰기 권한이 있고, bar라는 파일이 없으면 새 파일을 위한 아이노드를 배정하기 위해 아이노드 비트맵으로 이동
5. 아이노드 비트맵을 읽어 사용 가능한 아이노드 번호 찾기
6. 아이노드 비트맵에서 해당 아이노드 번호 사용중으로 표시
7. foo 디렉터리의 데이터 블록으로 돌아와 ("bar", inodenum_of_bar) 추가
8. 새로 배정한 bar 아이노드 읽고(default 값)
9. bar 아이노드에 메타데이터 쓰기
10. bar라는 파일이 생성되어 foo가 수정되었으므로, foo의 아이노드 갱신

• write()

11. bar 아이노드를 읽고 새로운 데이터를 위한 디스크 블록을 할당하기 위해 데이터 비트맵으로 이동
12. 데이터 비트맵을 읽고 사용 가능한 디스크 블록 찾기
13. 데이터 비트맵에서 해당 디스크 블록 사용중으로 표시
14. 할당 받은 디스크 블록으로 가서 데이터 쓰기
15. 작업이 끝나면 bar 아이노드로 돌아와 수정된 정보 갱신

캐싱과 버퍼링

• 파일을 읽고 쓰는 것은 많은 I/O 발생 --> 자주 사용되는 블럭을 메모리에 캐싱
• 쓰기 캐시: 쓰기 시점을 연기(쓰기 버퍼링, write buffering)
• 적은 수의 I/O로 일괄 처리(batch)
• 쓰기 자체를 피할 수 있다: 파일 생성 후 즉시 삭제하는 경우, 컴파일 과정에서 생기는 임시 파일 등
• fsync(): 쓰기 버퍼링으로 인한 예기치 않은 데이터 유실 방지, 호출시 갱신된 내용을 디스크에 강제적으로 기록

41 지역성과 FFS(Fast File System)

• 문제1: 기존 파일 시스템은 디스크를 마치 RAM처럼 사용하여 디스크 헤드를 이동시키는데 많은 시간 소요
• 문제2: 디스크의 빈 공간을 효율적으로 관리하지 않아 단편화(fragmentation) 발생

디스크에 대한 이해

• 파일 시스템의 자료 구조와 할당 정책을 "디스크에 적합"하게 설계
• 파일 시스템의 인터페이스는 그대로 유지: open(), read(), write(), close()
• 내부 구현 방식 변경
• 거의 모든 현대의 파일 시스템은 기존의 인터페이스를 그대로 사용하면서 성능과 신뢰성 또는 기타 다른 목적으로 내부를 최적화한다

실린더 그룹

• 디스크를 여러 개의 실린더 그룹(cylinder group)으로 분할
• 각 그룹별로 아이노드 비트맵과 데이터 비트맵을 두어 관리
• 아이노드와 파일의 데이터 블록을 같은 그룹에 할당하여 아이노드와 데이터 간의 긴 탐색 방지
• FFS는 파일과 그 파일이 속한 티렉터리 블록을 같은 그룹에 할당
• 긴 파일 이름 지원
• 심볼릭 링크 개념 도입
• FFS 이후, 파일 시스템 연구 증가