마지막 프로젝트가 끝났다.
구현하면서 알게된 내용을 간단하게 정리해 보려고 한다.

파일 시스템은 900개 ~ 1000개가 존재할 만큼 매우 많다. FAT, NFTS나 EXT4 같은 대표적인 파일시스템이 있지만, 이번 글에서는 좀 더 일반적인 개념을 다룬다.

파일

• I/O에 대한 추상화.
• 읽거나 쓸 수 있는 순차적인 바이트의 배열.
• pathname (path + filename)으로 식별될 수 있다.
• storage의 logical unit 이라고 볼 수도 있다. OS 내의 subsystem이 해당 파일을 physical storage에 mapping 해준다. 그 subsystem이 곧 파일시스템. 예를 들면, 유저가 파일에 쓰면 운영체제가 storage에 써준다.

• 파일의 유형에는 일반 파일, 디렉터리, 심볼릭 링크 가 있다 (대표적으로).
• 파일은 유저 data (실제 data)에 해당하기 때문에, 그 data를 관리하기 위한 meta-data가 반드시 필요하다. 이는 아이노드(inode)라는 자료구조에 저장된다.
• 아이노드는 파일마다 고유하게 가지는 메타데이터 저장 자료구조이다. 위의 3가지 종류의 파일 역시 각각 자신의 고유한 아이노드를 가져야 한다.

디렉터리

• 상식적으로 알려져 있듯이 파일의 위치를 나타내는 계층적인 구조이다. 가장 최상위 디렉터리인 root 디렉터리가 존재한다.
• "디렉터리도 블록으로 존재한다."
• 조금 더 구체적으로 말하자면, 디렉터리 안에는 파일 또는 하위 디렉터리가 존재할 텐데, 이러한 정보들(directory entry 목록) 또한 분명 storage에 적혀야 할 것이다. 이러한 정보를 storage에 저장하기 위해, 실제 data와(directory entry 목록) meta-data(아이노드)를 가진 파일처럼 디렉터리 또한 storage에 저장한다는 것이다.
• 그래서 디렉터리도 하나의 특수한 파일로서 취급된다.
• 하나의 directory entry는 하나의 <항목의 이름, 아이노드 번호> 쌍이다.
• example.
  Root Directory

항목의 이름	아이노드 번호	파일 유형(실제 저장 x)
.	2	디렉터리
..	2	디렉터리
hello	10	일반 파일
hello2	10	일반 파일 (하드 링크)
hello3	12	심볼릭 링크 (hello3->hello)

하드 링크 vs 심볼릭 링크

• 파일을 생성할 때, 두 가지 작업이 필요하다.
  1. 고유한 아이노드를 만들기.
  2. 아이노드에 사람이 읽을 수 있는 이름을 연결하고 <항목의 이름(파일 이름), 아이노드 번호>, 그 연결 정보를 디렉터리에 생성하기.
• 고유한 아이노드를 가지는 하나의 파일에 대해서,
  • 하드 링크는 추가적인 연결정보이다. 즉, 위의 두 가지 작업 중 2번 작업만 수행하는 것이다.
    link()시스템 콜로 생성할 수 있다. 새롭게 링크하려는 이름 항목을 디렉터리에 생성하고, 원래 파일과 같은 아이노드 번호를 가리키도록 한다.
  • 심볼릭 링크는 해당 파일을 가리키는 새로운 파일이다. 그래서 위의 두 가지 작업 모두가 다시 일어난다.
    그 새로운 파일의 내용에는 원래 파일의 경로명이 저장된다.
• 결국 하드 링크, 심볼릭 링크는, 같은 파일을 가리키는 여러 개의 서로 다른, 사람이 읽을 수 있는 이름을 만들기 위해 사용된다.
• example.
  hello : original file
  hello2 : hard link to hello
hello3 : symbolic link to hello

파일 삭제

• 파일 삭제는 unlink 일 뿐이다.
• 파일을 삭제할 때 입력하는 명령어 rm은 내부적으로 unlink() 시스템 콜을 호출한다.
• 앞서 하드 링크를 생성할 때 호출했던 link()는 원래 파일의 아이노드의 참조 횟수(reference count or link count)를 증가시킨다. 심볼릭 링크의 link는 참조 횟수에 포함되지 않는다.
• unlink()가 호출되면 이름과 해당 아이노드 번호 간의 "연결" 을 끊고(해당 directory entry를 제거함) 참조 횟수를 하나 줄인다.
• 여기 저기서 해당 파일과 관련한 unlink()가 호출되어, 결국 참조 횟수를 0으로 만드는 unlink() 호출이 발생하는 그 순간에, 파일 시스템은 그제서야 비로소 아이노드와 관련된 데이터 블럭을 해제하면서 진정으로 파일을 "삭제" 한다.
• 결국 파일의 고유한 정체성은 아이노드가 가지고 있는 것으로 이해하면 된다.

fsync ( )

• 앞서 말했듯, 유저가 파일에 쓰면 운영체제가 storage에 써준다. 다른 말로, '유저는 해당 데이터를 가까운 미래에 영속 저장 장치에 기록해 달라고 파일 시스템에게 요청한다'.
• 하지만 성능상의 이유로 파일 시스템은 쓰기를 일정 시작동안 메모리에 모은다 : 버퍼링. 즉 write() 시스템 콜의 정상적인 return이, disk에 쓰기가 완료되었음을 의미하지는 않는다.
• 여기서 persistence(영속성) 과 performance 사이의 딜레마가 발생한다. 버퍼링을 사용하다 보면 성능은 개선될 수 있으나, crash consistency 문제가 발생할 수 있다. 버퍼에만 데이터가 적히고 disk에 commit 되지 않은 상태로 예상치 못한 crush가 발생하여 데이터가 유실될 수 있는 것이다.

• 따라서 응용프로그램이 명시적으로 자신의 write() 요청들을 disk에 commit(flush) 할 수 있는 API가 제공된다 : fsync()
• 프로세스가 특정 파일 디스크립터에 대해 fsync()를 호출하면 파일 시스템은 지정된 파일의 모든 dirty 데이터 (갱신된 데이터) 들을 disk에 강제로 내려보낸다. 이 모든 쓰기가 처리된 후에 fsync()가 정상적으로 return 된다.
• 어떤 경우에는 파일 foo가 존재하는 디렉터리도 fsync() 해주어야 한다. 디렉터리도 파일의 형태로 disk에 저장되기 때문이다.

참고자료

• Operating System : Three Easy Pieces
• 권영진 교수님 강의 자료
• linux man page