레퍼드를 깔고 나면 타이거와 비교해서 크게 달라진 점이 없다고 느끼게 된다. 약간의 투명 효과와 독 디자인 정도가 달라보인다. 마치 태터툴즈 1.0에서 텍스트큐브 1.5로 업그레이드 할 때 처럼 아주 약간의 차이가 있어 보인다.
속을 들여다보면 의외로 다른 점이 많이 보인다. (이것도 태터툴즈와 텍스트큐브간의 관계같다) 디렉토리 구조는 이젠 BSD나 기타 유닉스 계열의 운영체제와 상당히 비슷하게 되었다. 예전에는 원하는 라이브러리나 실행 파일을 찾기 위해 whereis를 동원해도 나오지 않는 파일들 같은 경우에는 고생해서 찾았는데, 이제는 보통 '거기 있어야 할 파일들은 거기에 있다.' 매우 반가운 변화이다.
외형적으로 가장 크게 변한 부분은 타임머신 기능이다. 스페이스 같은 것은 이미 다음다음 단계의 데스크탑 이동 개념이 compiz fusion 등에 구현되어 있기 때문에 그다지 특이해 보이지 않는다. 타임머신의 경우에는 우선 눈에 보이는 것이 압도적이다.
빨려 들어갈 것만 같다.
당연히 이게 어떻게 돌아가는지 궁금해서 파봤다.
결론부터 이야기하자면 전혀 새로운 기술은 없지만 아이디어의 승리이다. 처음 생각해 낸 사람은 빙고를 외쳤을 듯.
쉽게 하려고 해도 컴을 살짝 뒤벼보지 않은 사람에게는 약간 어려운 이야기가 될 듯 하니 설명을 몇가지 붙인다. 아마 대부분의 유닉스 계열 운영체제 사용자에게는 너무나 익숙한 이야기일 듯 하다.
우리가 '파일'이라고 하는 것은 디스크 위에서 inode 라고 부르는 데이터 단위로 취급된다. 파일마다 붙이는 일종의 번호라고 생각하면 된다. 그 inode를 가리키는 이름들이 있는 것이고, 그게 일반적으로 파일 이름이다.
저만치 길동이가 있다. 그런데 태어날 때 부터 길동이가 길동인 것은 아니다. 나중에 이름을 그렇게 붙였기 때문에 길동이가 된다. inode가 그 사람 자체를 의미한다면 길동은 그 inode에 붙은 파일 이름이다.
그런데 inode에 하나의 이름이 붙을 필요는 없다. 사람이 태어나면 기본적으로 이름을 하나 붙이게 된다. 하지만 예명도 있을 수 있고, 두 얼굴의 삶을 사는 사람은 '지킬박사와 하이드씨' 마냥 이름도 두 개 일 수 있다. 마찬가지로 inode에도 여러개의 이름이 붙을 수 있다. 이걸 하드 링크라고 한다.
하드 링크는 하드하다. 하나의 하드 링크로 파일을 수정하면 모든 파일이 함께 수정되고, 모든 하드링크를 지워야만 해당되는 inode가 지워진다. 예를 들면, 지킬 박사가 하이드씨로 변신했을 때 하이드씨가 밥을 먹으면 지킬 박사도 배가 부르다. 같은 사람에게 이름이 두개 붙은 것이기 때문이다.
반면 윈도우 운영체제에서 '바로 가기(shortcut)'라고 부르는 것이나, 유닉스에서 심볼릭 링크(symbolic link)라고 부르는 것은 위와 다르게 소프트 링크라고 부른다. 이 경우는 어떤 '파일 이름' 을 가리키는 링크이기 때문에 지워도 원래 파일은 전혀 영향을 받지 않는다. 원래 파일이 이름을 바꾸거나 해도 소프트 링크는 원래 파일을 찾지 못한다.
마이크로소프트 윈도우 운영체제의 NTFS나, 리눅스의 EXT, 맥오에스의 HFS나 솔라리스의 ZFS등의 모든 파일 시스템은 소프트 링크와 하드 링크를 모두 사용할 수 있다. 운영체제에 따라 제한이 걸리거나 차이점은 존재하지만 공통적으로 하드 링크 기능이 있다. 위험할 수 있기 때문에 기본적으로는 막혀 있을 뿐이다.
Mac OS X 레퍼드의 타임머신의 원리는 정말 간단하다. 1시간마다 모든 파일을 외장 하드 드라이브의 시간 이름이 붙은 (backup-2007-10-30-205954 처럼) 디렉토리의 아래에 복사한다. 그런데 이 과정에서 같은 파일 이름을 갖고 생성시간과 용량이 같은 파일이 이미 복사되어 있다면 파일을 복사하지 않고 바로 전 시간에 백업한 파일의 하드 링크를 생성한다. 파일이 변경되어 있으면 그 파일을 복사한다. 이후에 백업되는 파일들은 그 복사한 파일로 하드 링크를 만들게 된다.
타임머신에 사용하는 외장 하드디스크의 구조.
이 쯤 되면 원래 아시거나 위의 설명을 읽으신 분은 원리가 이해 될 듯.
결과적으로 inode에 비하여 파일 수가 훨씬 많아지게 된다. 120 기가 바이트의 하드 디스크에 70기가의 크기를 갖는 디렉토리가 몇십개씩 생성된다. (하드 링크로 생성되므로 실용량의 몇 배도 가능하다) 이러한 트릭?을 이용하여 백업 당시의 파일 시스템 상황을 그대로 기록한다. 특별한 기술을 더하지 않고도 마치 당시에 존재했던 파일 시스템을 돌아다니듯이 모든 일을 할 수 있게 된다.
각각의 파일 시스템을 그냥 그대로 가지고 있는 것이기에 백업을 하기 위한 특별한 기술이 필요하지 않고, 따라서 백업 및 탐색 시스템을 만들기 위해 고려해야 하는 부분이 엄청나게 줄어든다. 백업 솔루션이라고 부르기에는 사기스러울 정도로 쉬운 방법이다. 하지만 완벽한 사기다. 백업의 궁극적 목표는 당시의 파일 구조를 그대로 가져 오는 것이기 때문이다.
윈도우에서도 도입하면 어떨까? 검색해본 바로는 NTFS는 최대 1023개의 하드 링크만을 지원한다. 그런데 예전에 연구실에서 데이터 보관을 위해 서버 만들면서 시도해 본 바로는 더 되는 것 같기도 하더라. (디렉토리 구조로 데이터를 년월일 구조로 정리한 후, 쉽게 읽기 위해서 한 디렉토리로 하드 링크를 만들었었다)
