cedis 님의 블로그

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은 메모리를 더 많이 쓰게 만드는 기술이 아니라, 아직 메모리에 없는 상태도 설명할 수 있게 만드는 약속이었다.이 문장이 이번 주 회고의 중심이다. 그래서..

Project 3 VM 시리즈 5편파일을 주소공간에 연결하고, fault와 dirty bit 기준으로 읽기와 write-back을 처리하는 흐름을 정리한다.이번 글에서 다루는 것mmap은 파일 내용을 단순히 read로 복사하는 기능이 아니다. 파일의 일정 구간을 유저 주소공간에 연결하고, page fault와 dirty bit를 기준으로 읽기와 되쓰기를 나누는 VM 기능이다.mmap 요청을 syscall에서 어떤 조건으로 거르는지 본다.file-backed page가 어떤 metadata를 들고 있는지 확인한다.lazy file page가 fault 시점에 읽히고, munmap/eviction 시점에 dirty page만 파일에 쓰이는 흐름을 정리한다.기준 코드글의 기준은 week11-team-03-pi..

Project 3 VM 시리즈 4편물리 메모리가 부족해졌을 때 frame을 고르고, page 종류별로 안전하게 내보내는 흐름을 읽는다.이번 글에서 다루는 것SPT가 page의 장부라면 frame table은 실제 물리 메모리 칸의 장부다. 이번 글에서는 frame이 부족할 때 어떤 frame을 희생시키고, page 종류에 맞게 어떻게 내보내는지 정리한다.page와 frame의 생명주기를 분리해서 본다.second-chance eviction이 accessed bit를 어떻게 사용하는지 본다.anonymous page가 swap disk로 나갔다가 다시 들어오는 흐름을 코드 기준으로 따라간다.기준 코드글의 기준은 week11-team-03-pintos-vm의 pair-a 브랜치다. COW는 이번 구현 범위..

Project 3 VM 시리즈 3편SPT에 없는 주소를 실패로 볼지, 새 stack page로 만들지 판단하는 기준을 정리한다.이번 글에서 다루는 것이번 글은 SPT에 없는 주소를 어떻게 판단할 것인가를 다룬다. VM에서는 SPT에 없다고 바로 죽이면 안 되는 경우가 있다. 대표적으로 stack이 아래 방향으로 자라야 하는 상황이다.stack growth 후보를 판단하는 기준을 본다.user mode와 kernel mode에서 사용할 rsp가 달라지는 이유를 정리한다.syscall의 user pointer 검증이 lazy page와 stack growth를 함께 고려해야 하는 이유를 확인한다.기준 코드글의 기준은 week11-team-03-pintos-vm의 pair-a 브랜치다. COW는 이번 구현 범..

Project 3 VM 시리즈 2편파일을 먼저 다 읽는 방식에서, 접근한 page만 fault 시점에 읽는 구조로 바뀐 흐름을 정리한다.이번 글에서 다루는 것이번 글의 핵심은 실행 파일을 load 시점에 전부 읽지 않는 것이다. pair-a 구현은 실행 파일의 각 구간을 SPT에 먼저 등록하고, 실제 파일 읽기는 page fault가 났을 때 수행한다.load 시점에는 page와 aux만 등록한다.page fault 시점에 vm_try_handle_fault()가 SPT를 찾아 claim한다.uninit page의 initializer가 실행되며 파일 내용이 frame에 채워진다.기준 코드글의 기준은 week11-team-03-pintos-vm의 pair-a 브랜치다. COW는 이번 구현 범위에서 제외한..

Project 3 VM 시리즈 1편PML4만으로 설명되지 않는 lazy page와 VM 메타데이터를 SPT로 분리해서 읽어본다.이번 글에서 다루는 것Project 3 VM을 시작하면 가장 먼저 부딪히는 질문은 “페이지가 아직 물리 메모리에 없는데도 어떻게 정상 상태로 관리할 수 있나?”이다. 이 글은 그 답으로 등장한 SPT(Supplemental Page Table)를 정리한다.PML4와 SPT가 서로 다른 일을 한다는 점을 먼저 분리한다.가상 주소 하나가 struct page로 연결되는 흐름을 본다.SPT 검색, 삽입, 삭제 코드가 이후 lazy loading, stack growth, swap, mmap의 발판이 되는 이유를 확인한다.기준 코드글의 기준은 week11-team-03-pintos-vm..

Pintos Project 2 완성 정리: 85/95에서 95/95까지 간 코드 흐름이번 글은 이미 구현된 main branch를 기준으로, 남아 있던 실패 테스트를 닫기 위해 어떤 코드를 추가했는지 정리한 글이다. 목표는 단순히 “어디를 고쳤다”가 아니라, 왜 그 코드가 필요한지와 어떤 테스트를 해결하는지를 연결해서 다시 재현할 수 있게 만드는 것이다.핵심 요약복사본에서 기존 결과 파일을 모두 지우고 전체 테스트를 새로 돌렸다. 최종 결과는 다음과 같다.cd pintos/userprog/buildexport PATH=$PWD/../../utils:$PATHfind tests -name "*.result" -deletefind tests -name "*.output" -deletefind tests -n..