cp /floppy/TEST /tmp/test 명령어를 실행할 때, cp 프로그램은 원본이 MS-DOS 기반이고 대상이 Ext2라는 사실을 인지하고 있을까요?

그렇지 않습니다. VFS(Virtual Filesystem)는 사용자 애플리케이션과 실제 파일시스템 구현부 사이에 위치한 커널 계층입니다. 프로그램은 그저 open, read, write, close 같은 익숙한 시스템 콜만 호출하면 됩니다. 커널 안의 VFS가 알아서 "이 파일은 MS-DOS용 read 함수로, 저 파일은 Ext2용 write 함수로" 적절히 연결해 줍니다.

리눅스가 강력한 이유 중 하나는 "구조가 전혀 다른 디스크나 네트워크 상의 파일조차 마치 내 로컬 디스크의 파일처럼 자연스럽게 다룰 수 있다"는 점입니다. 이를 위해 VFS는 크게 세 부류의 파일시스템을 지원합니다.

마운트(Mount)는 단순히 폴더를 연결하는 것이 아니라, "이 지점부터는 다른 파일시스템의 루트 트리를 보여주겠다"는 의미의 '트리 교체' 작업입니다. 따라서 어떤 파일시스템을 특정 디렉터리에 마운트하면 그 디렉터리의 원래 내용은 잠시 가려지고, 마운트를 해제(unmount)하면 다시 나타나게 됩니다.

Ext2와 FAT은 내부 구조가 완전히 다릅니다. 하지만 커널은 Common File Model을 도입해 모든 파일시스템이 전통적인 Unix 파일 모델처럼 보이도록 추상화합니다. 심지어 FAT처럼 Unix식 디렉터리 개념이 없는 파일시스템조차도, VFS가 기대하는 형태로 메모리 상에서 구조를 동적으로 만들어냅니다.

VFS가 관장하는 영역은 단순히 open, read, write에 그치지 않습니다. 마운트/언마운트, 파일시스템 통계 조회, 디렉터리 조작(생성·삭제), 심볼릭 링크 처리, 권한 변경, 파일 잠금(file lock), 메모리 매핑(mmap), 비동기 I/O, 확장 속성(extended attribute) 조작까지 파일과 관련된 거의 모든 시스템 콜을 포괄합니다.

Superblock은 개별 파일이 아닌, '마운트된 파일시스템 전체'의 상태와 메타데이터를 대변하는 핵심 객체입니다. 파일시스템 전체를 관장하는 주민등록부와 같은 역할을 합니다.

파일의 이름은 언제든 유연하게 바뀔 수 있지만, inode는 파일의 본질적인 정체성을 나타냅니다. 파일시스템 내부에서 특정 파일을 유일하게 추적하고 식별하는 절대적인 기준은 파일 이름이 아닌 이 inode 객체입니다.

모든 inode는 현재 상태에 따라 다음 세 가지 리스트 중 하나에 반드시 속하게 됩니다. 현재 프로세스에 의해 활발히 쓰이고 있는 in-use 리스트, 데이터는 유효하지만 지금 당장은 쓰이지 않는 valid unused 리스트(효율적인 캐시 역할 수행), 그리고 메타데이터가 변경되어 디스크로의 쓰기 작업이 예약된 dirty 리스트입니다. 더불어 고속 검색을 지원하기 위해 'inode 번호와 소속 superblock 주소'를 결합한 값을 키(Key)로 삼아 전역 해시 테이블에도 꼼꼼히 등록됩니다.

File 객체는 디스크 상의 파일 데이터 그 자체를 의미하지 않습니다. 특정 프로세스가 대상 파일을 열었을 때 메모리에 동적으로 생성되는 '상호작용 세션(Session)' 객체입니다. 파일이 열릴(open) 때만 일시적으로 만들어지며, 디스크에는 이에 직접 대응하는 데이터 블록 이미지가 전혀 존재하지 않습니다.

File 객체는 속도 향상을 위해 filp라는 전용 슬랩(slab) 캐시를 통해 할당됩니다. VFS 계층이 파일을 새로 열어야 할 때 get_empty_filp() 함수를 호출하여 깨끗한 객체를 하나 얻어내고, 그 안에 inode의 i_fop 테이블을 복사해 넣는 식으로 초기화를 진행합니다.

Dentry(Directory Entry)는 "특정 디렉터리 내의 문자열 파일 이름과 그에 상응하는 실제 inode를 하나로 묶어 연결"해 주는 매개체입니다. 만약 /tmp/test라는 경로를 탐색한다면, /, tmp, test 각각에 대한 dentry 객체가 계층적으로 다뤄집니다. 이는 디스크에 직접 저장되는 데이터 구조가 아니라, 빠른 경로 해석 성능을 달성하기 위해 VFS가 메모리 상에 동적으로 찍어내는 논리 객체입니다.

현재 쓰이지 않는 unused dentry들은 LRU(Least Recently Used) 리스트로 정렬되어 관리됩니다. 메모리 압박이 심해져 캐시를 덜어내야 할 때면 가장 오랫동안 쓰이지 않은 꼬리 부분부터 가지치기가 이루어집니다. 중요한 점은, unused dentry가 특정 inode를 쥐고 참조하고 있다면 해당 inode 역시 메모리에 계속 살아남아 캐시 히트율을 높인다는 것입니다. 다시 말해, dentry cache가 inode cache의 수명을 튼튼하게 연장해 주는 앵커(Anchor) 역할을 수행합니다.

활성화된 프로세스가 파일 시스템과 원활하게 상호작용하려면 반드시 두 가지 핵심 상태를 관리해야 합니다. 첫째는 "내가 현재 시스템의 어느 디렉터리에 위치해 있는가(fs_struct)"이고, 둘째는 "내가 현재 어떤 파일들을 열어서 사용하고 있는가(files_struct)"입니다.

특수 파일시스템(Special Filesystem)은 물리적 디스크의 블록을 관리하는 대신, 커널 내부의 역동적인 자료구조나 상태 정보를 친숙한 파일 읽기/쓰기 인터페이스 형태로 래핑하여 사용자에게 제공합니다. 이는 물리적인 블록 디바이스(하드디스크 파티션 등)에 귀속되지 않기 때문에, 커널 측으로부터 Major 번호 0과 파일시스템만의 고유한 Minor 번호로 구성된 가상의 블록 디바이스 식별자를 부여받고 동작을 시작합니다.

Namespace는 '특정 프로세스의 관점에서 바라보는 마운트된 파일시스템들의 전체 트리 구조'를 뜻합니다. 리눅스 시스템에 존재하는 대부분의 프로세스는 1번 프로세스(init)의 장대한 namespace를 고스란히 복제하여 공유합니다. 하지만 clone(CLONE_NEWNS) 시스템 콜을 통해 프로세스 전용의 독립적인 namespace 우주를 새롭게 창조하면, 그 격리된 공간 안에서 수행된 마운트나 언마운트 작업은 오직 동일한 namespace를 공유하는 그룹 내에서만 유효하게 보이며 바깥 세상에는 전혀 영향을 미치지 않습니다.

터미널에 mount 명령어를 무심코 입력하면, 내부적으로 mount() 시스템 콜이 트리거되고, sys_mount()를 거쳐 거대한 마운트 로직의 본체인 do_mount()로 깊숙이 진입하게 됩니다.

사용자가 무심결에 입력한 /tmp/test라는 단순한 문자열 경로를 쪼개어 실제 파일의 메타데이터 실체인 inode 객체로 안전하게 변환해 내는 일련의 기나긴 과정을 Pathname Lookup이라고 부릅니다. 이 과정의 중추적인 두뇌 역할은 path_lookup() 함수가 도맡아 수행하며, 험난한 경로 해석의 최종 결과물은 nameidata라는 매우 특별하고 거대한 구조체 바구니 안에 소중히 담기게 됩니다.

파일을 새롭게 생성하거나(create), 무자비하게 삭제(unlink), 혹은 이정표 이름을 바꿀 때(rename)는 대상이 되는 맨 끝단의 마지막 파일 이름 그 자체보다, 그 녀석을 따뜻하게 품고 있는 '부모 디렉터리(Parent directory)'의 객체 정보가 실질적인 제어의 핵심 타깃이 됩니다. 이때 조용히 LOOKUP_PARENT 플래그를 넘겨주면, 경로를 파헤치던 link_path_walk() 알고리즘은 맨 마지막 요소를 섣불리 해석하지 않은 채 부모 디렉터리 지점까지만 도달하여 멈추고, 미처 다루지 않은 마지막 문자열 꼬리표는 nameidata.last 변수에 얌전히 따로 떼어 보관해 둡니다.

우리가 터미널 창에서 아무 생각 없이 툭 던지는 cp /floppy/TEST /tmp/test라는 마법의 명령어 한 줄은, 커널의 컴컴한 바닥 밑에서 거대한 톱니바퀴처럼 맞물려 돌아가는 read + write + open + close 시스템 콜들의 기가 막히게 정교한 조합 덩어리입니다. 각 단계마다 도대체 어떤 VFS 핵심 객체들이 땀 흘리며 움직이는지 그 적나라한 내부 민낯을 파헤쳐 봅시다.

만약 통제 불능의 두 프로세스가 우연히 같은 파일의 정확히 똑같은 오프셋 위치에 동시에 쓰기(write) 폭격을 가한다면, 디스크에 남겨진 최종 결과물은 누구도 예측할 수 없는 끔찍한 쓰레기 데이터로 망가져 버립니다. 이 끔찍한 파국을 막아내기 위해 Unix 계열의 운영체제들은 아주 오래전부터 평화를 수호하는 File Locking(파일 잠금)이라는 훌륭한 동시성 제어 메커니즘을 든든하게 제공해 오고 있습니다.

동일한 가여운 파일 하나를 향해 무수히 쏟아지는 각종 락 요청들은, 결국 해당 파일의 영혼인 inode 객체 내부에 자리 잡은 i_flock 단일 연결 리스트로 꾸역꾸역 집결하게 됩니다. 이때 __posix_lock_file()라는 심판관 함수가 출동해, 같은 inode에 이미 주렁주렁 매달려 있는 기존 FL_POSIX 락들의 범위를 하나하나 까보며 새로 들어온 락 영역과 무자비하게 충돌하는지(Overlap) 계산기를 두드립니다. 만약 불운하게도 뼈아픈 충돌이 발생했고, 새로 요청한 락이 기다림(Blocking)을 감수하는 성격이라면 치명적인 데드락(Deadlock)이 걸렸는지 먼저 재빠르게 검사한 뒤 통과되면 조용히 waiter 큐에 밀어 넣어 깊은 잠에 빠뜨립니다.