파일 시스템 개편안

이제 기존의 유닉스 파일시스템(트리 형식)은 벗어날 때가 되지 않았나?

현재의 유닉스 파일시스템은 현재 IPv4와 마찬가지로 갖가지 기능을 한데 짬뽕시킨 괴물이다. 그 짬뽕시킨 것 중에 개념상 매우 유용했던 부분이 사실 지금은 오히려 발목을 잡고 있다.

바로 '트리형 디렉토리' 개념이다.

디렉토리가 트리가 되면 여러 면에서 다루기가 편해진다. 모든 파일은 루트부터 시작해서 유니크한 이름을 가진다. '현재 디렉토리'란 개념을 도입하면 상대적인 개념도 도입할 수 있다. 하지만, '트리'라는 한계상 상위 디렉토리는 하나일 수 밖에 없으며 이는 파일을 분류할 때 큰 문제가 된다.

X11R6 라는 패키지가 있다. 이 패키지는 하나의 디렉토리 밑에 두고 싶다. 이 디렉토리는 /usr/X11R6를 차지하고 이 디렉토리 아래에는 bin, include, lib, 등등이 있다. 하지만, 유닉스의 특성상 실행파일은 /usr/bin, 라이브러리는 /usr/lib, 헤더파일은 /usr/include 아래에 있어야 하므로 /usr/bin/X11, /usr/lib/X11, /usr/include/X11 등으로도 상기 파일들이 접근이 가능해야 하는 문제가 있다.

유닉스에서는 이 문제를 'symbolic link'라는 편법으로 해결을 한다. 개념이 좋기는 한데, 이건 문제를 풀기보다는 덮어두는 것이다.


구글메일을 보시라, 이제는 디렉토리가 대세가 아니라 '레이블'이 대세다. 애초에 파일 시스템 설계 시에 파일 자체를 특성으로만 분류하여 디렉토리 체계를 없애고 레이블체계를 도입한 뒤 빠르고 안정적인 파일 접근 방법을 도입하면 될 것이다.
파일 특성은 다음과 같이 분류하는 것을 권장한다.

1. write는 거의 없고 대신 빠른 read 성능이 필요한 파일들 : 주로 프로그램 설치 시 패키지 형태로 설치되는 실행파일들 혹은 매뉴얼 파일들. 이들은 설치 시에 최대한 fragmentation을 제거하고 read에 최적화 시켜서 배치하며 디스크도 빠른 곳에 집중배치한다.

2. read/write가 빈번히 발생하고 파일들에 대한 접근이 많으나 크기가 상대적으로 작은 것: 주로 작업 문서같은 것. 빠른 인덱싱과 캐시 위주로 설계. 이 형식의 파일들은 removable media를 고려하는 것이 바람직함.

3. read가 거의 없고 log 형태의 write가 많은 파일: 주로 프로그램 로그파일이나 덤프파일.

4. read도 거의 없고 write도 거의 없는 형태: 백업 파일 혹은 패키지 복구용 압축파일이 주가 됨. CD같은 read-only매체에 응용.

5. write는 거의 없고 read through-put이 일정하게 유지되어야 하는 대용량 파일들: 미디어파일

... 등등등...

이런 형식을 레이블 형식으로 만들어 붙이면 된다. 패키지도 레이블화 해서 붙이면 된다. 물론 버전도 레이블로 붙는다.

사용방법을 보자.

X11R5 패키지의 바이너리 실행파일 xterm 이라고 가정해 보자.

1. 그냥 xterm : 현재 context에 의해 나머지 결정. 예를 들어 실행파일, X11R5 context였다면 xterm 실행파일이 실행되고, configuration file 이 context였다면 configuration파일이 선택된다.

2. xterm/config : xterm configuration 선택 (기본 액션: edit 혹은 view)

3. xterm/exec/version 2.0 : xterm 버전 2.0 바이너리 실행파일 선택 (기본액션: 실행)

4. delete */netscape : 넷 스케이프 관련파일 몽땅 삭제

5. list */avi : 모든 미디어파일 리스트

6. backup */doc/myproject : 내 프로젝트의 모든 문서 백업

... 등등등 ...

자, 어떤가? 훌륭하지 않은가? 이걸 디자인해서 구현만 하면 될텐데...