cedis 님의 블로그

Project 4 File System 시리즈 3편하위 디렉터리까지 만들었다면 다음 문제는 user program이 그 디렉터리를 어떻게 다루느냐이다. Project 4는 directory도 open()으로 열고, fd를 통해 readdir, isdir, inumber를 호출하게 한다.핵심부터 말하면이번 구현에서는 fd table을 크게 갈아엎지 않고, 디렉터리 inode도 struct file로 열었다. 대신 file_is_dir(), file_readdir(), file_inumber() 같은 wrapper를 추가해서 syscall 계층이 같은 fd 경로로 파일과 디렉터리를 구분하게 했다.fd에서 디렉터리 entry까지user fd정수 fdfd tablefd → file handlestruct fil..

Project 4 File System 시리즈 2편1편에서 FAT와 파일 확장을 만들었다면, 이번에는 파일 이름을 찾는 방식 자체를 바꾼다. Project 4의 디렉터리 테스트는 더 이상 모든 파일이 root 아래에 있다고 봐주지 않는다.핵심부터 말하면기존 파일 시스템은 파일 이름 하나를 root directory에서만 찾으면 됐다. Project 4에서는 /a/b/c, ../x, 현재 작업 디렉터리, ., ..까지 처리해야 한다. 그래서 파일 생성과 삭제도 “부모 디렉터리 찾기 + 마지막 이름 처리”로 나누었다.경로 해석 흐름입력../tmp/a시작점절대경로면 root, 아니면 cwdtoken 순회.., tmp, a결과마지막 inode 또는 부모 dir1. thread가 현재 작업 디렉터리를 가져야 한다..

Pintos Project 3 · Copy-on-Write앞선 VM 글에서는 SPT, lazy loading, stack growth, frame table, swap, mmap까지 정리했다. 이번 글은 Project 3의 Extra인 COW(Copy-on-Write)를 다룬다. 핵심은 단순하다. fork 때 페이지를 바로 복사하지 않고, 부모와 자식이 같은 frame을 읽기 전용으로 공유하다가, 누군가 write를 시도하는 순간 진짜 복사한다.검증 기준이 글은 COW가 들어간 Pintos VM 코드를 별도 복사본에서 다시 빌드하고, COW 공개 테스트를 직접 실행한 결과를 기준으로 작성했다. 추가로 기존 최종 체크 로그에서 전체 VM 테스트 통과 기록도 확인했다.fresh 검증 · tests/vm/co..

Project 4 File System 시리즈 1편Project 3까지 완성된 코드 복사본 위에서 Project 4를 구현했다. 이번 글은 그중 첫 번째 축인 FAT 기반 파일 확장을 실제 코드 기준으로 정리한다.핵심부터 말하면기존 Pintos 파일 시스템은 파일이 디스크에서 연속된 sector에 저장된다고 보는 구조였다. Project 4에서는 파일이 커질 수 있고, 디스크 빈 공간이 항상 연속되어 있다는 보장도 없다. 그래서 inode에는 “첫 cluster”만 저장하고, 다음 cluster는 FAT 테이블을 따라가도록 바꿨다.이전 구조의 한계inode가 시작 sector와 길이만 알면 파일 위치를 계산할 수 있었다. 하지만 이 방식은 파일 확장과 조각난 빈 공간에 약하다.바뀐 구조inode는 첫 c..

Jungle WIL · Pintos Project 3이번 주의 베이스는 page fault였다지난 Pintos 회고에서 나는 “완성된 교향곡에서 베이스를 찾는 과정”이라는 문장으로 OS를 읽는 경험을 정리했다. Project 1에서 그 베이스가 interrupt와 테스트 케이스였다면, Project 3에서 다시 찾은 베이스는 page fault였다. 처음에는 page fault를 단순한 실패로 봤지만, 지나고 보니 그것은 lazy loading, stack growth, swap-in, mmap을 한 박자로 묶는 입구였다.이번 주를 한 줄로 정리하면VM은 메모리를 더 많이 쓰게 만드는 기술이 아니라, 아직 메모리에 없는 상태도 설명할 수 있게 만드는 약속이었다.이 문장이 이번 주 회고의 중심이다. 그래서..