- 시스템 메모리 증가
- 더 많은 데이터가 캐시되면서 디스크의 사용은 대체적으로 쓰기 위주가 되었고 읽기는 캐시에서 처리되었다.
- 임의 I/O와 순차 I/O의 성능 간의 격차
- 탐색과 회전 지연 비용은 매우 천천히 감소하고 있다.
- 워크로드에서 기존 파일 시스템들의 성능이 좋지 않았다.
- 예를 들어, 파일 시스템은 크기가 하나의 블록인 새 파일을 생성하기 위해 많은 수의 작업을 수행한다.
LFS 로그기반 파일 시스템
모든 갱신을 디스크에 순차적으로 기록하는 것이 핵심
디스크 기록시, LFS는 모든 갱신 정보(메타데이터 포함)를 세그멘트에 버퍼링한다.
세그먼트가 가득차면, 디스크에서 빈 공간을 찾아 한번에 기록한다. LFS는 기존의 내용을 덮어 쓰지 않는다. 대신 항상 비어있는 곳에 세그먼트를 쓴다.
디스크에 순차적으로 쓰기
읽기동작의 순차적 변형은 원래부터 불가능, BUT 쓰기는 파일 시스템이 쓰기 위치를 선택할 수 있다. 어떻게 하면 모든 쓰기를 순차 쓰기로 변형할까?
이때 데이터블록을 기록하면 데이터만 갱신이 되는 것이 아니라 메타데이터도 같이 갱신 되어야 한다.
순차적이면서 효율적으로 쓰기
❌ 순차적 ⇒ 효율적 ❌, 아래는 이에 대한 예시이다.
T 시간에 주소 A위치에 하나의 블럭을 썼다고 가정 잠시 뒤 T+a 시간에 디스크의 주소 A+1위치에 쓰기 함
➡️ 첫번째와 두번째 쓰기 사이에 디스크는 회전하였다., 두번째 쓰기의 경우 디스크에 기록되기 전에 플래터를 회전해야한다.
➡️ 회전이 $T_{rotation}$ 이 걸린다면, 디스크 표면에 두번째 쓰기를 실행하기 전까지 $T_{rotation}+a$ 시간을 기다려야한다.
✅ 순차적인 순서로 쓰는 것만으로 디스크의 최대 성능을 달성하기 힘들다 !
✅ Write buffering
디스크에 쓰기 전에 LFS는 갱신 내용을 메모리에 보관한다. 갱신된 내용이 충분히 쌓였다면 디스크로 한 번에 모두 내려 보내서 효율적인 디스크 작동을 도와준다.
Segment
한번에 디스크에 기록하는 단위, 집합으로 묶어서 쓰기 위해 사용하는 쓰기 단위
LFS가 디스크에 쓰기전에 얼마나 많은 업데이트를 버퍼링 해야할까?
⇒ 디스크에 따라 다르다.
아이노드 찾기
일반적인 UNIX 파일 시스템에선 정해진 위치에 배열로 배치
in LFS
아이노드가 디스크 전역에 흩어져 있다. 또한 원 위치에 덮어쓰기를 하지 않기 떄문에, 최신 아이노드의 위치가 계속 변한다.
아이노드 맵 (imap)
아이노드 번호를 입력으로 하여 가장 최신 아이노드의 디스크 위치를 구한다. 디스크에 아이노드가 기록될 때 imap은 새로운 위치를 가리키도록 갱신된다.
imap은 안전하게 보관되어야 한다. 그렇다면 imap은 디스크 어디에 저장할까 ?
imap을 디스크의 고정된 위치에 배치하는 방법이 있다. imap은 자주 갱신 된다. 파일 시스템의 내용이 변경될 경우 imap을 새로 기록해야한다. 잦은 갱신으로 성능이 저하되는 것을 막기 위해
imap을 새로 기록된 데이터와 아이노드들 옆에 함께 기록한다.
체크 포인트 영역: Checkpoint Region (CR)
체크포인트 영역은 최신의 아이노드 맵을 이루는 블럭들을 가리키는 포인터(주소)를 갖고 있다 CR영역을 읽어서 아이노드 맵의 조각들을 찾을 수가 있다.
약 30초 주기로 주기적으로 갱신이 된다.
LFS, 디스크에서 파일을 읽는 과정
메모리에 아무것도 없다고 가정
- 먼저 체크포인트 영역을 읽는다. 체크포인트 영역은 전체 아이노드 맵 블럭들을 가리키는 포인터들을 갖고 있다.
- 그러고 LFS는 아이노드 맵 전체를 읽어서 메모리에 캐시한다.
- 파일이 아이노드 번호를 구한다. LFS는 imap 의 아이노드 디스크 주소 매핑에서 아이노드 번호를 찾아서 가장 최신의 아이노드를 읽어드린다.
- 파일에서 블럭을 읽으려면 LFS는 일반적인 UNIX 파일 시스템이 수행하는 동일한 절차를 밟는다.
- imap 전체가 캐시되어 있기 때문에 LFS가 추가로 하는 일은 imp에서 아이노드 주소를 찾아 읽는 것 뿐이다.
디렉터리 관리 방법은?
LFS는 어떻게 디렉터리 데이터를 저장할까?
dir/foo 파일 만들기
아이노드 맵은 디렉터리 파일 dir과 생성된 f 의 아이노드 위치를 갖고 있다.
dir 디렉터리에 존재하는 f 파일 읽기
- 먼저 아이노드 맵에서 디렉터리 dir의 아이노드 위치를 파악한다(A3)
- 그 후 기렉터리 데이(A2)의 위치를 얻기 위해 디렉터리 dir의 아이노드를 읽는다.
- 디렉터리의 테이블 블럭에서 (f,k)의 파일명과 파일의 아이노드 번호 매핑 정보를 파악한다.
- 아이노드 번호 k(A1)의 아이노드 위치를 찾기 위해 아이노드 맵을 다시 한번 조회한다.
- 최종적으로 A0에 있는 데이터 블럭을 읽는다.
Garbage Collection
LFS의 문제는 갱신된 파일을 계속 디스크의 새로운 위치에 쓴다. ⇒ 예전 값 디스크에 남는다
• Updating data block D0
• Appending a block to file k
LFS는 파일의 최신 버전만을 유지한다. LFS는 주기적으로 이전 버전의 데이터와 아이노드 그리고 다른 자료 구조들을 찾아 제거한다.
이 작업으로 디스크 블럭들을 해제하여 추후 쓰기 요청에 사용될 수 있도록 한다.
⇒ 가비지 컬렉션의 일종
LFS의 가비지 컬렉터는 세그먼트 단위로 동작
- 쓰기 작업의 효율성을 위해 큰 공간 단위로 공간을 해제한다.
- 가비지 컬렉터는 주기적으로 오래된 세그멘트들을 읽은 후에 해당 세그멘트들에서 최신 블럭들의 개수를 파악한다.
- 최신 버전 블럭들을 새로운 새그멘트로 이동
- 유효 블럭들을 모두 이전한 후, 해당 세그멘트는 빈 공간으로 표시한다.
⇒ 가비지 컬렉터는 M개의 기존의 세그멘트들을 읽은 후에, 해당 내용으로 N개의 새로운 세그멘트들에 체운다( N<M) 그리고 N개의 세그멘드를 디스크의 새로운 위치에 쓴다. 이전의 M개의 세그멘트들은 해제가 되며 파일 시스템이 추후 요청되는 쓰기들을 처리에 사용한다.
블럭의 최신 여부 파악
가비지 컬렉터를 사용하기 위해선 어떤 블럭이 살아있고 죽은 건지 알아야한다.
Segment summary block
각 데이터 블럭D에 대해 D가 속한 파일의 아이노드 번호와 파일 내에서 오프셋을 저장
어떤 블럭을 언제 정리하는가?
언제 정리 해야될까
주기적으로 수행하는 방법이나 유휴 시간에 한다. OR
디스크가 가득찰때
어떤 블록을 정리해야 할까
Hot segment : 해당 세그멘트의 내용이 빈번하게 갱신되는 세그멘트
Cold segment : 몇 개의 dead block 들이 있지만 대부분의 블럭들은 갱신이 되지 않는 세그먼트
✅ 콜드 세그먼트는 자주, 핫 세그먼트는 긴 간격으로 클리닝 하자
크래시로부터의 복구와 로그
LFS에서는 디스크에 쓰는 도중에 시스템이 크래시되면 어떻게 될까
LFS는 쓰기들이 Log로 구성된다. ➡️ 즉 !, 체크포인트 영역에 첫번째와 마지막 세그멘트를 가리키는 포인터를 둔다.
각 세그멘트는 다음 세그멘트를 가리킨다. ⇒ 일종의 Linked List
[ 크래시가 발생하면 LFS는 어떻게 대처할까 ? ]
체크포인트 영역이 갱신되는 도중에 크래시가 발생하는 경우
CR은 원자적으로 갱신이 되어야한다. ⇒ LFS 두개의 체크포인트 영역을 둔다.
- 먼저 체크포인트 헤더를 기록한다.(현재시간포함)
- 체크 포인트 영역에 내용을 쓴다.
- 최종적으로 체크포인트 영역의 마지막 블럭을 갱신한다.
✅ 이를 이용하여 체크 포인트 영역을 일관성 있게 갱신할 수 있다.
세그먼트가 갱신되는 도중에 크래시가 발생하는 경우
LFS는 30초마다 CR을 갱신한다. 그래서 파일 시스템 스냅샷은 최신의 것이 아닐 수 있다.
⇒ Roll forward 적용
[출처]
https://github.com/remzi-arpacidusseau/ostep-translations/blob/master/korean/README.md
ostep-translations/korean/README.md at master · remzi-arpacidusseau/ostep-translations
Various translations of OSTEP can be found here. Help the cause and contribute! - remzi-arpacidusseau/ostep-translations
github.com
해당 책을 기반으로 정리하였습니다.
'Computer Science' 카테고리의 다른 글
[CS]프로세스와 스레드 (0) | 2025.04.18 |
---|---|
운영체제를 알아보자 (2) | 2025.03.31 |
[OSTEP 운영체제 정리] - File system implementation (0) | 2024.06.24 |
[OSTEP 운영체제 정리] - File and Directories (0) | 2024.06.24 |
[OSTEP 운영체제 정리] - IO and HDD (0) | 2024.06.24 |