Foundry
운영체제
중급
핵심

파일시스템과 inode

파일 이름과 실제 데이터가 어떻게 분리되어 있는지, 그리고 컨테이너가 쓰는 계층 파일시스템

파일시스템과 inode

파일 이름과 파일 자체는 다른 것이고, 그 사이를 잇는 것이 inode 다

inode 가 담는 것

담는 것담지 않는 것
파일 크기파일 이름
소유자와 그룹
권한
시각 정보 (수정, 접근, 변경)
링크 수
데이터 블록 위치

이름이 없다는 것이 핵심입니다. 이름은 디렉터리가 들고 있습니다. 디렉터리는 "이름과 inode 번호의 목록"입니다.

구조내용
디렉터리 항목"report.txt" 는 inode 12345
inode 12345크기, 권한, 데이터 위치
데이터 블록실제 내용

이 구조가 설명하는 것들

현상이유
하드 링크로 같은 파일에 여러 이름여러 디렉터리 항목이 같은 inode 를 가리킨다
파일을 지워도 프로세스가 계속 읽는다링크 수가 0 이 되어도 열어둔 프로세스가 있으면 실제 삭제를 미룬다
이름을 바꾸는 것이 빠르다디렉터리 항목만 고친다. 데이터는 그대로
디스크 공간은 남는데 파일을 못 만든다inode 가 소진됐다

네 번째가 실무에서 당황하는 상황입니다. 작은 파일을 수백만 개 만들면 용량은 남아도 inode 가 먼저 고갈됩니다.

하드 링크와 심볼릭 링크

항목하드 링크심볼릭 링크
가리키는 것같은 inode경로 문자열
원본을 지우면남은 이름으로 접근 가능깨진 링크가 된다
다른 파일시스템불가가능
디렉터리불가가능

컨테이너의 계층 파일시스템

컨테이너 이미지는 여러 층으로 쌓이고, 아래 층은 읽기 전용입니다.

성격
이미지 층들읽기 전용. 여러 컨테이너가 공유한다
컨테이너 층쓰기 가능. 컨테이너마다 하나

읽기는 위에서 아래로 찾아 내려가고, 쓰기는 위 층으로 복사한 뒤 수정합니다. 이것이 쓰기 시 복사입니다.

얻는 것내용
이미지 공유같은 기반 이미지를 쓰는 컨테이너가 그 층을 공유한다
빠른 시작복사 없이 층을 겹쳐 올리기만 한다
작은 저장 공간바뀐 것만 컨테이너 층에 남는다
대가내용
첫 쓰기가 느리다큰 파일을 조금 고쳐도 전체를 복사한다
층이 많으면 읽기가 느리다아래로 찾아 내려가는 비용
삭제가 실제 삭제가 아니다위 층에 "지워짐" 표시만 남아 이미지 크기가 줄지 않는다

세 번째가 이미지 크기를 줄이려는 사람이 자주 만나는 문제입니다. 한 단계에서 큰 파일을 넣고 다음 단계에서 지우면, 지워졌다는 표시만 추가되고 원본은 아래 층에 남습니다. 같은 단계 안에서 넣고 지워야 합니다.

면접에서 이렇게 나옵니다

Q.inode 에 저장되지 않는 정보는 무엇인가요?

파일 이름입니다. 이름은 디렉터리가 들고 있습니다.

inode 가 담는 것디렉터리가 담는 것
크기, 소유자, 권한이름과 inode 번호의 짝
시각 정보
링크 수
데이터 블록 위치

이 분리가 여러 동작을 설명합니다.

현상설명
한 파일에 여러 이름(하드 링크)여러 디렉터리 항목이 같은 inode 를 가리킨다
이름 변경이 빠르다디렉터리 항목만 바꾼다. 데이터 이동이 없다
열어둔 파일을 지워도 읽힌다링크 수가 0 이어도 사용 중이면 실제 해제를 미룬다
이름 없이 존재하는 파일지운 뒤에도 프로세스가 쥐고 있는 동안 공간을 차지한다

마지막이 실무에서 겪는 상황입니다. 로그 파일을 지웠는데 디스크 공간이 안 돌아오는 경우가 이것입니다. 프로세스가 그 파일을 열어둔 상태라 해제되지 않습니다. 프로세스를 재시작하거나 파일을 비우는 방식으로 다뤄야 합니다.

흔한 실수: 파일 내용이 inode 에 있다고 답하는 것. inode 는 데이터가 어디에 있는지를 담고, 내용은 데이터 블록에 있습니다.

Q.디스크 공간이 남는데 파일을 만들 수 없는 이유는 무엇인가요?

inode 가 소진된 것입니다. 파일시스템을 만들 때 inode 개수가 함께 정해집니다.

자원소진되면
데이터 블록용량 부족 오류
inode공간이 남아도 새 파일을 만들 수 없다

작은 파일을 대량으로 만드는 워크로드에서 발생합니다.

흔한 원인내용
세션 파일사용자마다 작은 파일 하나
캐시 파일정리되지 않고 쌓인다
메일 큐메시지마다 파일
빌드 산출물정리 안 된 임시 파일
확인과 대응내용
확인df -i 로 inode 사용률을 본다
어디인지 찾기디렉터리별 파일 개수를 센다
대응오래된 파일을 정리한다
근본작은 파일을 쓰는 구조를 바꾼다. DB 나 오브젝트 저장소로

흔한 실수: 용량만 확인하고 정상이라 판단하는 것. df -h 는 여유로 보이므로 df -i 를 함께 봐야 합니다. 두 지표가 별개입니다.

Q.컨테이너 이미지 레이어에 어떤 파일시스템이 쓰이나요?

여러 층을 겹쳐 보이게 하고 쓰기는 위 층으로 복사하는 계층 파일시스템을 씁니다. 리눅스에서는 대개 overlayfs 입니다.

성격
이미지 층들읽기 전용. 컨테이너들이 공유한다
컨테이너 층쓰기 가능. 컨테이너마다 하나
동작내용
읽기위 층부터 아래로 찾아 내려간다
쓰기위 층으로 복사한 뒤 수정한다
삭제위 층에 지워졌다는 표시를 남긴다

이 방식이 맞는 이유는 컨테이너 요구와 맞아떨어지기 때문입니다. 대부분의 파일은 읽기 전용이고, 같은 기반 이미지를 여러 컨테이너가 공유하며, 시작이 빨라야 합니다. 복사 없이 층을 겹쳐 올리기만 하면 됩니다.

대가내용
첫 쓰기가 느리다큰 파일을 조금 고쳐도 전체를 복사한다
층이 많으면 읽기가 느리다아래로 탐색하는 비용
삭제해도 이미지가 안 줄어든다아래 층에 원본이 남는다

쓰기가 많은 데이터는 층을 쓰지 않고 볼륨으로 빼는 것이 답입니다. DB 데이터를 컨테이너 층에 두면 쓰기마다 복사 비용이 붙습니다.

흔한 실수: 한 단계에서 큰 파일을 넣고 다음 단계에서 지워 이미지 크기를 줄이려는 것. 지워졌다는 표시만 추가되고 원본은 아래 층에 남아 크기가 그대로입니다. 같은 단계에서 넣고 지워야 합니다.

Q.하드 링크와 심볼릭 링크는 어떻게 다른가요?

항목하드 링크심볼릭 링크
가리키는 것같은 inode경로 문자열
원본을 지우면남은 이름으로 접근 가능깨진 링크가 된다
다른 파일시스템불가가능
디렉터리불가가능
크기원본과 같게 보인다경로 문자열 길이
원본과 구분구분이 없다. 둘 다 동등한 이름링크임을 알 수 있다

마지막 줄이 개념의 핵심입니다. 하드 링크에는 원본이라는 개념이 없습니다. 두 이름이 같은 inode 를 동등하게 가리키고, 링크 수가 0 이 될 때 실제로 해제됩니다.

심볼릭 링크는 그저 경로를 담은 작은 파일입니다. 그래서 가리키는 대상이 없어도 만들 수 있고, 상대 경로를 담으면 옮겼을 때 다른 곳을 가리킵니다.

쓰이는 곳선택
버전 전환심볼릭 링크. current 가 v1.2 를 가리키게
중복 제거하드 링크. 같은 내용을 한 번만 저장
다른 디스크의 파일 참조심볼릭 링크
백업 스냅샷하드 링크. 바뀌지 않은 파일은 링크로

흔한 실수: 디렉터리에 하드 링크를 만들려는 것. 순환 구조가 생겨 파일시스템 순회가 무한 반복될 수 있어 금지돼 있습니다.

먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.

더 깊이 공부하기

읽었으면 문제로 확인해보세요

운영체제 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.