Pintos lab4 file systems review

📕 File System

유저는 파일이름과 디렉토리만 알면 파일을 열고, 쓰고, 저장하는 데 밑단의 일들을 신경쓰지 않고 컴퓨터를 쓴다. OS는 이를 위해 file system을 통해 disk를 효율적으로 관리하고, 메모리에 연산이 끝난 데이터들을 disk에 옮겨주고 작업할 내용을 불러와 줌으로써, memory hierarchy을 최적화해 컴퓨팅 성능을 향상시킨다. 또한 변경된 내역들을 저장해 컴퓨터가 종료되고 부팅된 이후에 이전 작업들이 안전하게 보호되게끔 한다.

파일 시스템은 지금까지 랩 중에 가장 어려웠다... 그 전에는 템플릿도 잘 되어 있었고, 적어도 이 분을 고쳐라라는 정도의 설명들이 있었는데, 이번 주는 개념적인 부분까지 공부가 되있는 것을 가정하고 git book에 간단하게 적혀있었다. OS마다 개념은 같으나 구현하는 방식이 다르고 사용하는 정책이 다르기 때문에 Pintos에서 어떤 기능을 필요하는데 파악이 필요했다. 그래서 개념에 대해서 공부를 하고 코드를 뜯어내보면서 어떻게 돌아가는지 파악하는 과정이 필요했다. 함수마다 일일히 pritnf 찍고 test케이스 돌려가면서 흐름을 보고 터지는 부분에서 어떤 기능이 필요할 지 파악했다.

👉 Indexed and Extensible Files

이전 Pintos는 freemap이라는 bitmap을 통해서 disk를 관리하고 있었다. Bitmap을 사용하면 구현이 간단하지만 disk의 크기 커졌을 때 bitmap의 크기 또한 커져야한다는 단점이 있다. 이를 FAT를 사용해 대체하고, FAT table을 저장하는 sector를 미리 지정해 놓음으로써 컴퓨터가 꺼졌다 켜져도 이전 disk 사용정보들을 보관할 수 있도록 구현한다. 구현 뒤에 disk의 sector는 다음 모양이 된다.

부팅, 종료시 FAT를 저장하고 불러오는 코드는 이미 구현이 되있으니, 이에 맞춰서 FAT를 구현하고 sector와 cluster를 연결시키는 부분을 구현하였다. 새로운 cluster들을 관리하고 이를 FAT table에서 linked 시켜서, sector가 떨어져 있어도 연속적인 파일로 불러올 수 있도록 한다. 이를 통해 유저가 파일에 접근하는 순서는 file->inode->inode_disk->start sector->cluster->fat->next cluster-> next sector .... 가 된다. 이렇게 되도록 inode.c의 free map 부분들을 모두 수정한다.

파일은 inode를 하나씩 가지고 있다. 파일을 open하면 inode on memory가 memory에 올라간다. inode on disk는 파일에 대한 정보를 disk에 저장하는 녀석이다. inode on memory는 파일을 열때마다 독립적으로 메모리에 올라가지만, inode on disk는 하나다 파일에 뭔가 변화가 일어난다면 inode on disk에 disk write 해준다. inode on disk에는 데이터를 저장하는 시작 sector를 저장해 놓는데 이를 통해 FAT에 접근할 수 있고, extensible하게 만들 수 있는 것이다.

이전 pintos는 file length가 static하였는데, 이를 dynamic하도록 수정했다. write length(size+offset)이 파일이 inode length 보다 크다면, 파일 length를 변경하고, 필요하다면 추가적인 sector를 할당해준다.

👉 Subdirectories and Soft Links

이전 pintos는 root directory에 모든 파일을 저장되게끔 되있다. 또한 '/a/b'라는 주소가 들어와도 경로로 인식하지 못하고 하나의 filename으로 인식한다. dir, dir entry는 이미 구현이 되있다. dir은 file 구조체와 같다, 메모리에 올라가는 녀석이고, dir_entry는 file의 data라고 생각하면 될 것 같다. dir를 열면 dir entry를 통해 디렉토리 안의 파일이나 directory로 접근할 수 있다. thread마다 cwd를 구현해서 절대 경로와 상대경로를 구현했다.

먼저 주어진 입력을 parse하는 함수를 만든다. strtok 함수를 이용해서 '/'단위로 끊어서 dir 열고 dir entry를 검색해 다음 dir를 찾는다 최종적으로는 마지막에 작업해야 할 working dir와 마지막 filename을 반환한다. 이를 사용해서 create, open, remove에서 subdirectories를 구현했다. '..'와 '.' 그리고 다양한 예외 케이스까지 구현하는데 시간이 많이 걸렸다. 사용된 inode를 모두 말끔히 닫아줘야 inode remove도 동작하고 disk에도 잘 저장된다는 걸 깨닫는데 많은 시간을 소모했다...

soft link는 고민 끝에 새로운 file,director 같은 새로운 element로 받아드리는게 편했다. 여기에는 오로지 파일 경로만이 data로 저장 되어 있어서 접근시 따로 parsing해서 inode를 검색해서 반환시키도록 전체적인 시스템에서 손을 봤다... 덕분에 파일 접근할 때 마다 is_link() 함수를 통해 확인하고... 4byte의 주소를 위해 한 sector를 할당하고.. 매우 비효율적으로 느껴지지만 이렇게 짜지 않으면 test case를 통과할 수 없었다....

👉 Buffer Cache

운영진의 배려로 구현에서 제외해주셨다!! 실제로는 test case도 없고 성능향상에 관한 부분이라... 구현하지 않아도 무방하지만, 아마 memory hierarchy를 효율적으로 이용하기 위해서는 꼭 필요한 부분이겠지....
혹시 나중에라도 구현하기 위해 적어놓았던 메모를 적어둔다....
1. 버퍼는 64 sectors를 할당, mapping memory는 list로
2. clock 알고리즘, next fit
3. 정기적으로 swap out 필요. eviction 알고리즘
4. inode read,write의 buffer 부분을 buffer cache로 교체
5. IO를 위한 dedicated thread 구현...(잘모르겠다...)
6. using VM type(file cache) -> using mmap area..

👉 Synchronization

이미 전 lab들을 통해 synch 잘 설계되있어서 큰 어려움 없이 통과 될 수 있었다. inode를 통해 thread마다 파일에 접근할 수 있으니 이 부분은 됬고... 다만 file write 시에 extensed 되지 않는 부분에 대해서는 모든 thread가 수정 가능해야 한다고 적혀있었지만, file write에 대한 filesys lock를 막아놓고도 test case를 모두 통과하여 일단 넘어갔다...

👉 Pintos를 마치며...

예전에 잠깐 전산학과 수업을 들을 때, 개발자는 머리 속의 완벽히 이해를 하지 않으면 코딩을 시작하지 말라라는 말씀을 교수님이 해주셨는데, 당시도 그렇고 Pintos 초반도 그렇고 일단 해보면서 구현하는게 맞지 않나? 라는 생각을 했었다. Pintos 후반으로 갈 수록 구현 난이도가 높아지고 머리속으로도 기억해야 될 게 많아질 수록 그 때 교수님 말씀이 옳았음을 깨닫고 내 방식도 바뀌어갔다... 무작정 컴퓨터 앉아 있는다고 코딩이 짜여지는 것이 아니라... 밥먹다가, 운동하다가, 자기 전에 누워 있다가, 아 이렇게 하면 되겠구나 깨닫고 노트에 정리를 대충이라도 해놓고 구현하게 되었다. 물론 그렇게 짠 코드가 맞는다는 보장은 없지만...

또 하나 성장한 점은 집중력이다. 후반으로 갈 수록 코딩에 몰입할 수 있는 시간이 길어짐을 느낄 수 있었다. 저녁 끼니 때 코딩이 한창 잘 되면 얼른 끝내고 먹어야겠다 해놓고 정신차려보면 10시 반이었다...

아무튼 Pintos를 통해 컴퓨터에 대해서 이해할 수 있었고 밑단에 무슨일이 일어나는지 추상화라는 개념을 통해 이해할 수 있었다. 그 동안 멀리했던 전공책을 많이 읽어야 되겠다라는 생각도 하게 되었다. 앞으로 개발자로 살면서 어떻게 OS지식이 사용될지는 잘 모르겠지만, 적어도 "모르면 책보고 검색하고 코드보고 배운다!"라는 마인드 정도는 가질 수 있게 되었다.

Good bye Pintos!