거북이의 쉼터

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

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

마참내. 마지막 프로젝트이다. 3월에 마지막을 하고 있는 나도 정상은 아니야... K-핀토스로 개조되면서 가장 극심한 변화를 겪은 부분이기도 하며, 지난 번 진행할 때 격추된 부분이다. 극도로 조심히, 세밀하게 진행하도록 하자. 프로젝트 4는 여태 프로젝트들이 지난 프로젝트를 반드시 요구했던 것과는 다르게 프로젝트 2 위에 올리기만 해도 된다고 한다. 다만 점수가 깎일 뿐이지... ㅋㅋㅋㅋ 프로젝트 2 위에 직접 올리게 되면 10%의 점수가 차감된다. 프로젝트 3 위에 올리려고 한다면, filesys/Make.vars를 수정하라고 나온다. 죽이되든 밥이되든 프로젝트 3 위에 올릴 것이기에 수정하고 시작하자. 참고로 프로젝트 4의 Extra는 웬만한 일이 아니면 안 할 것이다. 첫 번째 이유는 기본 구현도..