XFS File System

이전에 카프카 브로커 작업을 하면서 저널 파일 시스템에 대한 글을 썼었다. 이제 리눅스 스토리지 쪽을 공부하면서 xfs, ext4를 다시 보게 되었는데, “저널링을 한다” 빼고는 내가 이것들에 대해 아무것도 설명할 수 없다는 걸 깨달았다…;;

그래서 이번 주말에 xfs, ext4를 제대로 살펴보면서 B+Tree 자료구조도 0-to-1으로 다시 구현해보는 시간을 가졌다.

이제는 xfs를 제대로 이해해볼 마음이 생겼다. 한번 들여다보자.

쓰기 성능 측면

수많은 CPU가 동시에 큰 데이터를 써도 병목 없이 처리하자.

1990년대에 대형 서버를 운영한다고 해봅시다. 그때도 이미 대형서버는 멀티 코어로 동작합니다.

그래서 각 CPU마다 각자의 작업을 동시에 수행하고 있습니다.

CPU0 : 로그 파일 생성
CPU1 : 데이터베이스 쓰기
CPU2 : 이미지 저장
CPU3 : 디렉토리 생성

멀티 코어 서버에서 동시에 파일시스템에 접근해 작업을 수행해야 합니다.

하지만, 파일시스템이 전체 쓰기 작업에 대해 단일 전역 락(single global lock)을 가지고 있다면, CPU가 동시에 작업을 수행하더라도 쓰기는 한번에 한 CPU만 가능합니다.

CPU0 작업중
CPU1 대기
CPU2 대기
CPU3 대기

이것은 디스크가 RAID로 묶여 있어도 동일합니다. RAID 디스크 위에서 파일시스템이 운영되기 때문이죠.

xfs의 설계자들은 “디스크가 느린게 문제가 아니라 파일시스템이 병렬성을 가지지 않는게 문제다”라고 보았습니다. 그래서 파일시스템을 N개의 독립적인 블록으로 나누고, 각 블록에 대해 메타데이터 락을 갖도록 분산합니다.

이 독립적인 블록을 “Allocation Group“이라고 합니다.

CPU0 → AG0
CPU1 → AG1
CPU2 → AG2
CPU3 → AG3

각 CPU는 개별 AG에 동시에 쓰기 작업을 수행합니다. 가 AG에 대해서 쓰레드가 동시에 파일 생성, inode 할당, 블록 할당, 디렉토리 수정 등의 파일시스템 쓰기 작업을 수행할 수 있습니다.

이것이 바로 “병렬 파일시스템“인 xfs 입니다.

왜 Allocation Group이 필요한가?

예전 파일시스템은 하나의 슈퍼블록으로 구성 되어 있었습니다.

Filesystem
├── Superblock
├── Inode Table
├── Data Blocks
└── Free Block Bitmap

파일 생성을 하려면, 빈 inode를 찾고, 빈 block을 찾고, bitmap을 수정하고, inode를 수정해야 합니다.

그리고 모든 CPU가 단일 객체에 접근하고 수정해야 합니다. 이러면 락 경합(lock contention)이 발생합니다.

xfs는 파일시스템을 Allocation Group이라는 단위로 쪼갰습니다.

그리고 각 AG는 독립적인 메타정보 객체를 가집니다.

AG0
├── Free Blocks
├── Free Inodes
└── Metadata
AG1
├── Free Blocks
├── Free Inodes
└── Metadata
...

그래서 각 CPU가 서로 다른 AG에 쓰기 작업을 한다면, 충돌이 발생하지 않습니다.

AG의 메타데이터는 B+Tree로 구현 되어 있습니다.

AG0

Free Space B+Tree
        │
        ├── (1000, 50)
        ├── (2000, 30)
        └── (5000, 100)
Inode B+Tree
        │
        ├── inode 1
        ├── inode 2
        └── inode 3

그래서 CPU0가 AG0의 B+Tree를 수정하는 동안, CPU1은 AG1의 B+Tree를 수정할 수 있습니다.

xfs를 이해할 때, 파일시스템을 데이터베이스처럼 생각하면 좀더 쉽게 와닿습니다.

• inode = DB 레코드
• B+Tree = DB 인덱스
• AG = 샤드(shard)
• CPU = 동시 트랜잭션

xfs과 기존 ext2의 차이는 Free Space를 관리하는 자료구조에 있습니다.

ext2는 Free Space를 bitmap으로 관리하지만, xfs는 Free Space를 B+Tree로 관리합니다.

B+Tree로 구현하면, 100GB 연속 공간 찾기 같은 질의를 더 빠르게 수행할 수 있습니다.

Delayed Allocation

쓰기 요청이 들어와도 즉시 블록을 할당하지 않음.

f.write(data)와 같은 일반적인 파일 쓰기는 파일 시스템에서 블록 할당 -> 데이터 쓰기 순서로 수행 됩니다.

Write 행위를 N번 연속으로 한다면, N x (블록 할당 -> 데이터 쓰기)가 이뤄집니다. 이러면, 데이터 Fragmentation이 발생하고, 디스크 I/O도 많아지며 Metadata Udpate도 자주 발생합니다.

Delayed Allocation은 이걸 지연처리해서 한번에 수행하는 아이디어 입니다.

f.write(data)가 수행되면, 일단 데이터를 Page Cache 메모리에 받아둡니다. 데이터 업데이트도 Page Cache 위에서 수행하고 Page Dirty 상태로 계속 업데이트 합니다.

여기까지는 메모리만 사용합니다. 그러다가 Page Cache Evict으로 인해 spill to disk 하거나, flush()가 발생하면 지금까지 메모리에 있던 내용을 모아 한번에 디스크 쓰기를 수행합니다.

write 4KB
write 4KB
write 4KB
write 4KB

↓ 아직 디스크 블록 미할당

(flush 시점)
16KB 연속 공간 확보

이렇게 하면, 매번 데이터 쓰기를 해서 주소가 이곳저곳 흝어지지 않고, 연속된 데이터를 연속된 공간에 넣을 확률이 높아집니다.

그리고 블록 할당을 한번에 처리하기 때문에, 메타데이터 업데이트도 감소 합니다.

이런 지연 쓰기는 대용량 쓰기 성능을 향상시킵니다. 로그 서버, DB, 영상 저장 등의 워크로드는 쓰기 작업이 계속해서 들어옵니다. 이걸 매번 처리하기보다는 묶어서 한번에 처리하는게 이득 입니다.

Extent 기반 공간 관리

블록 공간을 시작점과 연속된 블록의 크기로 표현하자.

블록 사이즈가 4KB, 파일이 16KB라면 4개 블록을 써야 하는데, 기존 파일시스템은 디스크를 분할한 블록 공간을 이렇게 저장 했습니다.

[100, 101, 102, 103]

만약, 파일이 1GB 였다면, 1GB / 4KB = 260K 블록을 숫자 배열로 기록 했습니다.

Extent의 아이디어는 연속된 블록 공간을 표현하기 위해 (start, length) 방식으로 표현합니다.

그래서 16KB 파일이 연속 블록으로 존재한다면, (start=1000, length=4)로 표현하면 끝입니다. 1GB 파일이라면, (start=1000, length=260K)로 2-size tuple로 끝입니다!

만약 파일이 조각난 블록으로 존재하더라도, Extent로는 (100, 3), (500, 2), (900, 4) 이렇게 표현하면 그만 입니다.

xfs의 3가지 모두를 채택 했기 때문에 강하다

• Allocation Group
• Delayed Allocation
• Extent 기반 관리

xfs는 위에서 설명한 3가지 기법을 1994년에 모두 가지고 있었습니다.

ext는 ext4(2008)이 나와서야 xfs가 채택 했던 장점들을 지원합니다. xfs가 1994년에 출시 되었으니 무려 14년의 시간이 걸린거죠. ext4에서는 병렬 쓰기를 지원하기 시작했지만, 그 구현은 xfs와 비교했을 때 사뭇 다릅니다. 어쨌든 ext4도 14년을 기다려 병렬 쓰기를 달성한 상태예요.

안정성

Metadata Journaling

저널 파일 시스템에도 적었지만, xfs는 저널링을 지원하는 파일시스템 입니다.

그중에서도 메타데이터에 대한 저널링을 지원하죠. 저널링에 대한 내용은 위의 포스트에서 자세히 적었기에 여기에서는 언급만 하고 넘어갑니다.

ext 계열에선 ext3(2001)에 저널링 기능이 추가 됩니다. 이것도 xfs가 1994년부터 지원했던걸 생각하면 무려 7년이 걸린거죠.

확장성

커널 개발자 관점에서는 XFS를 설명할 때 보통 “highly scalable filesystem” 이라고 부르지, “parallel disk filesystem” 이라고는 잘 부르지 않습니다. 핵심은 디스크보다 확장성(scalability) 에 있습니다.

xfs의 설계 목표는 “거대한 시스템에서도 성능이 무너지지 않는 파일 시스템”입니다. 그래서 시스템의 CPU가 늘어나는 경우를 쉽게 대응하고, 온라인으로 파일 시스템 킉 확장이 가능합니다!

온라인 확장

xfs는 운영 중인 파일 시스템을 xfs_growfs로 온라인 확장이 가능합니다.

xfs는 파일 시스템을 확장할 때, 기존 구조를 재배치 하지 않고, 뒤에 새로운 Allocation Group을 추가하는 방식으로 확장 합니다.

기존 XFS
+------+------+
| AG0  | AG1  |
+------+------+

디스크/LV 확장 후
+------+------+------+------+
| AG0  | AG1  | AG2  | AG3  |
+------+------+------+------+

뒤에 AG를 붙이는 방식이기 때문에, 파일시스템이 on-write/on-read 상태에서도 크기를 늘리면서 기존 데이터 유지가 가능합니다.

CPU 확장

디스크와 CPU는 독립적인 자원이기 때문에, 디스크를 유지하면서 CPU만 스펙업 하는게 가능합니다.

그래서 처음에는 1 CPU로 시작한 시스템이 4 CPU -> 8 -> 16 -> 64 CPU까지 확장할 수도 있죠.

CPU가 증가할수록 파일 시스템으로 들어오는 생성/삭제/쓰게 요청도 증가하게 됩니다.

기존의 ext2는 단일 메타데이터 락이 있기 때문에, CPU가 2배 늘어나더라도 디스크 쓰기 성능이 2배 늘어나는 걸 보장하지 않습니다.

하지만, xfs는 Allocation Group으로 디스크를 분할하고 병렬 쓰기가 가능했기 때문에, CPU를 2배 늘리면 디스크 쓰기 성능도 선형적으로 증가하는 추세를 보였습니다.

단, CPU가 늘어난다고 해서 기존에 할당한 AG 갯수가 늘어나는건 아닙니다. CPU 갯수 <= AG 갯수라는 부등식이 유지되는 환경에서는 CPU 코어 증가가 디스크 쓰기 성능과 비례하게 된다는 의미 입니다.

맺음말

카프카 브로커 작업에서 시작했던 xfs 시스템에 대한 궁금증은, 개발의 기초라고 할 수 있는 리눅스 시스템과 파일 시스템까지 보게 만들었습니다. 이제 묵은 궁금증을 해소 했으니, 다른 재밌는 주제들을 찾아서 내재화 하려고 합니다. 토스에서 일도 열심히 하고 틈틈히 실력도 늘리면서 화이팅!!!