거북이의 쉼터

이번에는 File Growth를 살펴볼 것이다. 분량은 짧긴 한데 지난 포스팅에 이어서 계속 작성하기에는 FAT에서 급작스럽게 파일 extension으로 넘어가는 것이라 흐름이 애매했다. 지금까지 핀토스에서 사용된 코드를 보면 파일을 생성할 때부터 어느 정도를 사용할 지 미리 지정해서 생성한 뒤, 할당된 부분만을 사용하였다. 현실에서는 전혀 그렇지 않다. 우리가 메모장을 열 때 얼마를 사용할지 지정하고 쓰지 않듯이, 핀토스에서도 파일을 생성할 때는 크기 0으로 생성한 뒤, 필요한 만큼 크기를 키우는 과정을 구현해야 한다. 파일이 자랄 수 있는데에는 크기 한계가 마땅히 없다. 메타 데이터를 제외하고 파일 시스템이 허용하는 만큼 커질 수 있으며, 루트 디렉토리에도 같은 논리에 의해 16개보다 많은 파일이 저..

해당 매뉴얼을 이해하는 데에는 FAT 방식에 대한 이해가 필요하기 때문에 FAT를 먼저 공부하고 왔다. 파일 시스템은 파일의 내용을 기본적으로는 섹터에 담아서 저장하며, 관리의 편의성을 위해 이러한 섹터들 중 연달은 섹터를 여러개를 모은 "클러스터" 단위로 관리한다. 파일이 한 클러스터 안에 다 담기지 않을 경우에는 여러 클러스터를 활용해 파일을 저장해야 할 것이다. 이 때, 사용되는 각 클러스터를 어떻게 관리할지가 주요한 문제이다. 버클리 FFS의 경우 이를 inode에서 indirect inode, double indirect inode 등으로 접근할 수 있도록 하였다. FAT는 그보다 훨씬 단순하다. 사용된 클러스터를 연결 리스트 방식으로 관리하는데에서 아이디어를 착안한 것이다. 예를 들어 한 파일..

아직 프로젝트 4 관련해서는 아무것도 한 게 없지만 가장 중요해보이는 것을 먼저 가져왔다. 결국 프로젝트 1부터 프로젝트 3까지 내가 사투를 벌여온 영역은 동기화 문제였고, 파일 시스템 동기화와 관련하여 가장 머리를 싸맨 기억이 많았다. 디버깅할 때 가장 엿같았던 기억을 선사한 것도 동기화 문제기에, 이쯤되면 동기화는 발작 버튼으로서 훌륭한 기능을 하게 되었다. 여태까지 파일 시스템은 내부 동기화 과정이 없어, 외부 동기화로 호흡기를 붙여야 간신히 호흡을 할 수 있는 상태였다. 그렇기에 코드가 조잡해졌고, 많은 프로세스를 돌릴 때, 락이 필요없는 부분까지도 락이 걸려있어야 하는 비효율성을 초래했다. 때문에 finer-grained 동기화 전략을 구현하는 것이 해당 파트의 목표이다. 각 엔티티에 따른 동작..

보호되어 있는 글입니다.