파일 시스템의 21가지 규칙: 제로부터 만드는 COW 파일 시스템 4

지난 글에서는 AI와의 협업에 관한 내용을 기록했습니다.

이번 글에서는 간단한 작업 사양을 조금 보충하여 이곳을 기점으로 삼습니다.

백지 위에 어떻게 건축 설계를 그릴까?――그리드다.

르네상스의 거장들은 어떻게 저토록 웅장한 거인들을 정확하게 그려냈을까?――등분선이다.

'21가지 군규'를 대략 모방하여 무언가를 작성해 보자. 이 파일 시스템에 몇 개의 선을 그어보자.

제1조 커밋의 출처는 묻지 않고, 증거만을 심사한다. 게이트(CI)를 통과한 규범적인 패치는 진지하게 다룰 가치가 있다. Show me the test.

제2조 모든 의사결정에는 실험에 의한 근거가 필수적이다. 명시적으로 면제된 경우를 제외하고는 그렇다. 실험 파일은 git에 커밋한다.

제3조 모든 의사결정과 설계는 표준 템플릿에 따라 기록으로 남긴다.

제4조 영원히 옳은 결정이란 존재하지 않는다. 의문이 제기된 결정은 반드시 검증되어야 한다.

제5조 본 프로젝트는 과거의 우수한 프로젝트 경험에서 배우지만, 구현은 본 프로젝트 고유의 특성에 맞춘다.

제6조 데이터 형식은 자족적이며 역추적 인덱스를 갖춘다. 데이터는 자신의 신원과 귀속을 스스로 증명할 수 있어야 한다.

제7조 인덱스 트리 등은 파생물이며, 폐기해도 좋다. 데이터의 복구는 트리에 의존하지 않으며, 트리는 고속 검색과 보조만을 위해 존재한다.

제8조 제7조에 근거하여, 파생물은 순수하게 유지한다. 파생물에 작은 데이터를 저장해서는 안 된다.

제9조 스트라이프 폭은 가변적이며, 풀스트라이프 쓰기에서는 절대 RMW(Read-Modify-Write)를 수행하지 않는다.

제10조 가짜 ENOSPC는 용납하지 않는다. 여유 공간으로 보이는 것은 실제로 사용 가능해야 한다.

제11조 암호화는 1급 기능으로 취급하여 슬롯을 예약하지만, 기본적으로 비활성화한다.

제12조 미래 확장을 위해 슬롯을 예약한다. 상황에 따라 벤더용 인터페이스도 제공한다.

제13조 데이터 단위는 32KiB, 인덱스 노드는 16KiB다. 32KiB는 체크섬의 최소 단위에서 결정되었고, 16KiB는 CPU 캐시와의 트레이드오프에서 결정되었다. 둘 다 SSD의 쓰기 단위에 맞춘 것은 아니다.

제14조 데이터 복구 코드와 테스트 코드는 본체 코드와 동등하게 취급하여 병행 개발한다.

제15조 검증 측 구현과 파일 시스템 측 구현은 코드를 공유하지 않고, 각각 독립적으로 구현한다. 공유하는 것은 포맷뿐이다.

제16조 충돌 테스트는 망라적으로 수행해야 하며, 샘플링으로 끝내서는 안 된다. 또한, 광역 테스트나 형식 검증을 대신할 수는 없다.

제17조 초기 단계의 순수성을 유지한다. 초기는 Linux 대응(브랜치)을 고려하지 않고, 트랜잭션을 축으로 개발한다.

제18조 첫 번째 계통은 SSD만을 지원한다. 디스크 종류는 incompat로 틀만 확보해 둔다. 여러 종류의 디스크에는 브랜치를 나누어 특화시키면 된다.

제19조 포맷 동결 전에는 파일 시스템 코드를 최적화하지 않고, 성능도 추구하지 않는다.

제20조 가비지 컬렉션에서는 GPU를 이용한 회수 알고리즘의 가능성도 염두에 둔다.

제21조 슬로건은 검토 중...

본문은 여기까지입니다.

**기여자(Contributor)**는 커뮤니티에 의한 협업이라는 생각에 근거한다. 한 사람의 힘에는 결국 한계가 있다.

제1조 이 프로젝트는 AI를 주축으로 하는 프로젝트이며, 첫날부터 AI의 유전자를 가지고 있다. 우리는 시대가 가져다주는 혜택을 누리면서도, 그 단점을 억누르지 않으면 안 된다. AI 주도의 프로젝트 처리량은 무한하지만, 인간의 정력에는 한계가 있다. 게시물의 처리량은 무한이어도 좋지만, 수용하는 처리량은 증거에 의해 제약된다.

의사결정・설계와 실험은 설계 단계에서 AI에게 주는 조작 매뉴얼이다. AI의 할루시네이션을 최대한 줄이고, AI의 자율성을 높이기 위해, 그리고 의사결정・설계・실험이 컨텍스트를 잃지 않도록 설계되었다.

제2조 의사결정이나 설계는 공상이 아니다. 실험으로 검증하고, 하나하나의 실험 코드 속에 발판을 찾아야 한다. 발판 없는 결정이나 설계는 공상에 불과하다. 결정이 틀려도 괜찮지만, 그것이 논증을 거쳤다는 것은 보여져야 한다. 실험은 증거의 일부로서 영원히 기록으로 남겨야 한다.

제3조 AI 주도 프로젝트에서는 지식 기반(Knowledge Base)이 전체 공정에서 가장 중요한 부분이 됩니다. 기록으로 남겨진 이러한 지식은 향후 의사결정이나 회고의 중요한 거점이 됩니다. 문서는 표준 템플릿에 따라 작성합니다. 템플릿은 변경해도 좋으며, 변경했다면 AI에게 하나씩 수정하도록 시키면 됩니다.

제4조 많은 결정들은 실제 구현(Implementation)이 진행되면서 적절하지 않게 될 수 있습니다. AI가 이력이나 맥락을 의심할 수 있는 능력을 고려하여, AI가 의문을 제기할 수 있는 선택지와 힌트를 준비해 두어야 합니다. 동시에, 이러한 의문을 방치해서도 안 됩니다. 그렇지 않으면 공정이 크게 지연됩니다.

제5조 이 파일 시스템의 설계는 기존의 파일 시스템과는 약간 다릅니다. 선행하는 파일 시스템을 기반으로 하여 그 우수한 알고리즘이나 설계를 가져옵니다. 하지만 독자성 또한 유지해야 합니다. 우리는 별개의 프로젝트이며, 기존 구현을 그대로 가져와서는 안 된다고 AI에게 항상 주지시켜야 할 필요가 있습니다.

데이터 구조 부분은 singlefs의 핵심 구현체이며, singlefs 데이터에 대한 구상을 간결하게 설명하고 있습니다.

제6조 singlefs의 데이터는 32KiB의 고정 크기입니다. 데이터에는 데이터 단위 헤더와 본체가 포함되며, 이 둘은 단단히 결합되어 분리될 수 없습니다. 이렇게 함으로써 데이터는 태어날 때부터 신분을 갖게 되며, 동시에 역참조 인덱스(Inverse Index)를 통해 자신이 어떤 트리에 속하고 어느 객체의 것인지를 보여줄 수 있습니다. 즉, 데이터 자체가 자신의 상황을 설명할 수 있어, 신분이나 소속을 증명하기 위해 인덱스 트리 기록이 필요하지 않습니다.

제7조 제6조에 근거하여 데이터가 스스로를 증명할 수 있다면, 데이터를 기록하는 트리의 지위는 한 단계 낮아집니다. 데이터가 자신의 신분과 소속을 설명할 수 있기 때문에, 최악의 경우에도 인덱스 트리는 버리고 재구축할 수 있습니다.

제8조 제6조의 32KiB라는 데이터 크기는 작은 파일을 저장할 때 용량 비대화를 초래합니다. 그러나 제7조에 근거하여 인덱스 트리는 순수하게 유지되어야 합니다. singlefs는 인덱스 트리 위에 작은 데이터나 기타 구조화된 정보를 저장하지 않습니다. 현재로서는, 작은 데이터를 모으는 방식, 즉 여러 개의 작은 데이터를 하나의 32KiB 데이터에 모아서 저장하는 방식으로 해결할 것을 구상하고 있습니다.

제9조 스트라이프(Stripe)란 디스크를 가로질러 데이터를 저장하는 개념입니다. 데이터의 안전성을 확보하기 위해 여러 디스크에 동시에 기록해야 합니다. 예를 들어 기존 RAID5는 3개의 디스크가 필요하며, 2개가 데이터이고 1개가 패리티이므로 매번 64KiB 고정으로 기록합니다. 그렇다면 32KiB의 데이터만 있다면 어떻게 될까요? 이 경우 구 데이터를 읽어와 패리티를 재계산하여 다시 기록하게 됩니다. 이 과정 중에 전원이 꺼지면, 데이터와 패리티가 불일치하게 됩니다(Write Hole).

반면 singlefs에서는 스트라이프를 가변적으로 만듭니다. 같은 상황에서 32KiB의 데이터를 저장한다면, 2개의 디스크에만 기록합니다. 64KiB의 데이터라면 3개에 기록합니다. 읽기를 수반하지 않고 매번 정확히 가득 채워서 기록합니다. 전원 차단으로 인한 데이터 손실 위험도, 용량 사용량도 훨씬 작아집니다.

제10조 기존 파일 시스템에서는 인덱스 트리가 권위이기 때문에, 파일의 업데이트는 인덱스 트리에 의존할 수밖에 없습니다. 따라서 인덱스 트리에 기록할 공간이 없어지면 파일을 쓸 수 없게 됩니다. 게다가 파일 삭제 역시 인덱스 트리 업데이트를 동반하므로, 삭제조차 할 수 없어 파일 시스템이 멈춰버립니다(Freeze). singlefs의 자립성(Self-contained nature)은 이 문제를 어느 정도 해결할 수 있지만, 아직 탐색 중입니다.

제11조 파일 암호화는 처음부터 포맷에 내장하는 기능이지만, 최초 동작 가능 버전에서는 구현하지 않고 포맷상의 비트만 예약해 둡니다(비활성화 시 모두 0). 트랜잭션 계층과 체커가 먼저 작동하게 된 후에 실제 암호화를 연결할 예정입니다. 활성화한 후 원래대로 되돌릴 수 있는지는 현재 미정입니다.

제12조 singlefs는 영역의 일부를 미래 확장 필드용으로 예약하고 있습니다. 또한, extend와 같은 필드를 벤더사 SSD에 개방할지 여부도 검토 중입니다. 낭비야말로 우리의 강점입니다.

제13조 32KiB의 데이터 단위는 사실 SSD에 맞춰 설계된 것은 아니다. 체크섬이 전체 단위를 덮기 때문에, 체크섬의 세분화(粒度)와 익스텐트(extent)의 세분화를 일치시켜 로직을 단순화하는 것을 목표로 했으며, 그 대가로 무작위적인 작은 읽기 작업에서 약 10% 정도 추가 비용을 지불한다. 16KiB는 인덱스 노드의 크기로, 이 수치는 CPU 캐시 측면의 트레이드오프를 고려하여 결정되었다. 16KiB 노드와 32KiB 데이터 단위는 별개의 단위이며, 두 개의 인덱스 노드를 합쳐 하나의 데이터 단위를 만드는 것은 아니다.

**테스트 및 복구(Recovery)**는 singlefs 자체의 테스트와 파일 복구 기준이다.

제14조 singlefs는 파일 시스템을 제로(zero)부터 다시 작성하는 것이며, 하위 데이터 포맷에도 독자적인 차이가 있다. 따라서 자신들만의 고유한 테스트 체계와 방법을 설계할 필요가 있다. 데이터의 복구성은 singlefs에게 가장 중요한 사항이므로, 테스트 코드, 복구 도구, 핵심 본체 코드는 같은 날에 구현한다. 각 마일스톤마다 서로 상호 검증한다.

제15조 테스트와 핵심 본체의 로직이 같으면, 같은 방향으로 치우친 버그를 발생시키기 쉽다. 따라서 테스트와 핵심 본체는 각각 별도로 구현한다.

제16조 일상적인 세자 간의 코드 교차 검증(クロスチェック) 외에도, QEMU 환경에서 전원이 꺼진 후 데이터가 각 스트림 상에서 어떤 상태가 되며 복구 가능한지를 포괄적으로 시뮬레이션하는 것이 singlefs의 핵심 테스트이다. 광역 테스트는 코드 내의 버그를 감지하고, AI가 코드를 작성할 때 '겉보기에 올바른 결과'를 내놓게 되는 것을 방지하기 위한 것이다. 형식 검증(formal verification)은 병렬 처리 기능에 필수적이다. singlefs는 엄격한 테스트로 버그를 조기에 발견하는 동시에 가시성(observability)도 높이고자 한다.

우선순위는 singlefs 개발 과정에서 그 특성에 따라 설계된 것이다.

제17조 singlefs는 트랜잭션(transaction)을 축으로 개발하기 때문에, FUSE 인터페이스와 같은 상위 계층용 개발은 뒤로 미뤄진다. 이는 리눅스 커뮤니티와의 호환성을 늦출 가능성이 있다. 하지만 그만큼 초기 개발의 복잡도를 낮추고 데이터 흐름에 집중할 수 있다. 나는 체력이 부족하고, 토큰도 충분하지 않다.

제18조 singlefs에는 디스크 매체 종류(회전식 디스크, SSD, ZNS 등)를 구분하기 위한 incompat 설정을 두었다. 이 설정을 발판 삼아 각종 매체를 극한까지 최적화할 수 있기를 기대한다. 다만, 같은 이유—체력 부족, 토큰 부족—로 인해 첫 번째 버전은 범용 SSD만 지원한다.

제19조 singlefs의 각 마일스톤에서는 다른 파일 시스템과의 교차 비교를 수행하지만, 이는 노드 단위의 데이터 기록에 근거한 것에 불과하다. 포맷 동결 전에는 성능을 위해 파일 시스템의 핵심 코드를 최적화하지 않는다.

제20조 singlefs의 가비지 컬렉션(Garbage Collection)은 무겁다. 표준적인 CPU 위에서 작동하는 GC 외에도, GPU에도 뭔가 맡기고 싶다. 물론, FTL이나 ZNS 같은 기능도 활용하고 싶다.

제21조 【큰 디스크는 회사의 것, 좋은 잠은 나의 것?】【와아!(WAAAGH!) 간다!】

후우, 겨우 끝냈다.

여기서는 키보드를 Agent 형님들에게 맡긴다.

토큰아, 도망쳐…….