파일시스템 요소들

기본요소

파일시스템은 커널(kernel) 또는 응용프로그램에서 저장하고자 하는 데이터를 저장장치에 기록하기 위한 방법을 제시하므로 이에 필요한 저장장치 및 논리적 요소들을 알아볼 필요가 있다.

저장장치 측면에서는 디스크의 섹터나 플래시 메모리의 블록 드잉 있을 수 있으며, 논리적 요소들은 클러스터와 파일, 디렉토리 등을 이야기할 수 있다.

클러스터

클러스터는 운영체제가 저장장치에 데이터를 읽고 쓰는 논리적인 기본 단위이며, 파일시스템에 따라서 그 크기가 고정되어 있기도 하고, OS가 파일시스템 생성 시 저장장치의 크기를 고려하여 클러스터의 크기를 조절하기도 한다.

클러스터의 크기는 저장장치의 크기 및 사용 용도에 따라서 달라져야 할 필요가 있다. OS에 의해 데이터를 읽고 쓰는 과정에서 파일시스템은 미리 정해져 있는 클러스터의 크기를 기본 단위로 하여 입출력을 하므로 클러스터의 크기가 4096Byte로 정해져 있는 경우라면 단 1Byte를 읽어 들인다 하더라도 4096Byte를 읽어야 한다. 단순히 읽어 들이는 상황이라면 문제가 되지 않겠지만 반대의 상황에서는 얘기가 틀려진다.

다음 이미지와 같이 크기가 작은 파일을 저장장치에 쓰고자 하는 경우 클러스터의 크기보다 파일의 크기가 작아서 공간이 남게 되면 나머지 공간은 사용이 불가능하게 된다.

 

 

 예를 들어 특별한 목적으로 저장장치를 이용하고자 하여 1KB 미만의 파일들이 대부분인 상황이라면 클러스터의 크기를 1KB로 설정해야 현명한 선택이다. 그렇지 않고 4KB로 설정하여싿면 모든 파일마다 3KB 정도의 공간이 낭비되므로 결국에는 실제 사용되는 영역보다 낭비되는 영역이 더 많아지는 상황도 있을 수도 있다.

공간적인 낭비가 있음에도 클러스터의 크기를 크게 정하는 이유는 성능적인 측면에 있다. PC를 사용하면서 처리 속도에 있어서 가장 큰 비용을 요구하는 작업 중의 하나는 바로 디스크 입출력이다. 예를 들어 10KB의 파일을 읽어 들이는 경우 클러스터의 크기가 1KB라면 10번의 I/O가 발생해야 하지만 클러스터의 크기가 4KB라면 단 3번의 I/O로 파일을 전부 읽어 들일 수 있다. 물론 이 경우 2KB 가량의 낭비되는 공간이 발생하기는 하나 요즘과 같이 대용량 하드디스크를 사용하는 경우 용량에 비해 디스크의 가격이 매우 저렴하므로 특별한 상황이 아니라면 이는 무시할 수 있을만한 정도이다.

또한 파일시스템의 역량과 저장장치의 크기에 따라서 클러스터의 크기가 저장장치의 사용에 중요한 요소로 작용할 수도 있다. 예로 FAT16과 같이 파일시스템의 주소 지정 방식에 16bit를 사용하는 상황이라면 클러스터의 크기에 따라 최대 사용할 수 있는 저장장치의 공간이 적잖은 차이를 보일 수 있다.

클러스터의 크기가 1KB라면 사용할 수 있는 저장장치의 크기는 최대 65,563 * 1,024 = 64MB가 되고, 클러스터의 크기가 4KB라면 사용 가능한 크기는 최대 65,536 * 4,096 = 256MB가 된다. 요즘 같이 대용량 디스크를 사용하는 경우에는 파일시스템에 따라 주소 지정 방식이 32bit, 48bit, 64bit 등 다양하게 사용되지만, 저장장치의 크기가 작고 가격이 비싸던 시절에는 상황에 따라 충분히 문제가 될 수 있을만한 일이다.

일반적으로 클러스터의 크기는 디스크를 포맷할 경우나 파일시스템을 생성하는 시점에 지정할 수 있으며, 최근의 대용량 하드디스크에서는 주로 4KB의 크기가 기본으로 지정되어 있으며, 플로피디스크의 경우에는 기본적으로 1KB로 지정되어 있다.

클러스터의 크기가 미치는 여러 영향에 대해 알아보았으니 저장장치의 활용도가 특별한 경우라면 이를 조절하여 최적화된 서비스를 운용할 수 있도록 하는 것도 좋을 것이다.

파일

일반적으로 OS의 개념에서 파일을 다루는 경우에는 파일명과 확장자의 종류를 비롯하여 여러 가지 파일의 속성에 대해 다루지만, 파일들을 이루는 요소들이 실제 저장장치에서 어디에 위치하고, 어떤 프로세스로 동작하는지에 대해서 알아보자.

파일시스템이란 결국 파일을 기록하기 위한 것이므로 파일을 이루는 구조와 그것을 관리할 수 있는 추가적인 방법을 제시하는 것이다. 파일은 속성을 기록하는 메타 데이터 영역과 실제 데이터를 기록하는 데이터 영역으로 나눌 수 있다. 메타 데이터라 함은 파일시스템에서 파일을 관리할 수 있는 정보 자체를 말하며 파일의 속성은 물론 실제 데이터를 기록한 위치를 찾아가기 위한 정보들을 포함한다. 모든 파일시스템들은 이러한 정보들을 어딘가에 저장해 두었다가 OS가 정보를 요청하면 해당 파일을 찾아서 정보를 조합하여 넘겨주면 사용자가 파일이라고 부르는 정보가 되는 것이다.

 

위는 간단히 파일 정보 요청 프로세스를 표현한 것이다. 생각해 보면 매우 간단한 원리이지만, 앞으로 분석할 파일시스템들은 결국 이와 같은 프로세스의 좀 더 진보적인 방법이라고 할 수 있다.

가상 파일시스템을 떠올려 보면 특정 OS가 원하는 정보들을 미리 정의하고, 관련 인터페이스를 제공하며, 실제 파일시스템들은 미리 정의된 정보를 충족시킬 수 있는 구현부를 제공해서 사용자의 요청에 만족하는 정보를 제공하면 그것을 파일이라고 부른다.

파일 데이터는 클러스터 단위로 읽고 쓸 수 있으며, 단 1Byte라도 사용한다면 1개의 클러스터 영역이 사용된다. 하나의 클러스터에 여러 파일 정보를 담을 수 있는 연구가 진행되고 있으며 주로 알려진 파일시스템에서는 스펙상으로 가능한 것도 있지만 실제로 사용되는 경우는 없다.

모든 파일시스템들은 파일 저옵를 관리하는 자료구조를 가지고 있으며, 이 자료구조에 의해 파일시스템의 성능에 큰 영향을 끼치게 된다. 예로 FAT는 연결 리스트로 되어 있고, NTFS는 B-Tree 를 사용한다. 두 알고리즘의 특성과 마찬가지로 검색 긴으에 있어서 NTFS가 FAT에 비해 좋은 효율을 보이는 등 여러 차이를 보인다.

디렉토리

디렉토리는 현존하는 모든 파일시스템들이 도입한 개념으로서 파일들을 계층화하고 그룹화 할 수 있다. 상,하위 개념의 디렉토리와 파일들은 그것들을 관리함에 있어서 많은 이첨을 제공하며, 때로는 이러한 개념을 뛰언머기 위한 링크 등의 방법을 제공하는 파일시스템들도 있다.

파일과 디렉토리는 크게 다르지 않다. 물론 파일과 디렉토리에 대한 속성 정보를 따로 만들어 놓고 이를 통해 파일과 디렉토리를 구분하여 관리하지만, 실제 안을 들여다보면 결국에는 비슷하다는 것을 알 수 있다. 파일의 경우 데이터 영역에 있어 파일 정보에서 그것의 위치를 가리킨다. 그런데 디렉토리라고 해서 데이터 영역이 존재하지 말라는 법은 없다. 디렉토리의 경우에도 데이터 영역이 존재하는데, 이 영역에서는 하위에 존재하는 디렉토리 및 파일 리스트들이 위치한다. 이러한 구조들은 특정 파일시스템에 국한된 것이 아니라 대부분의 파일시스템들이 이러한 구조로 되어 있다.

가장 상위 디렉토리의 경우 파일시스템에 따라서 관리하는 방법이 다르므로 해당 파일 시스템의 분석을 살펴보도록 한다.

부가요소

최근 사용되는 PC 및 서버 머신들은 여러 명의 사용자들이 동시에 접근하여 사용할 수 있으며, 시간에 구애받지 않고 높은 퀄리티의 서비스를 제공하기 위해 신뢰성을 높이는 여러 가지 기법들을 사용하고 있다. 파일시스템 역시 이러한 흐름에 뒤쳐지지 않고 계속 발전되어 왔다.

소유권

개인용 컴퓨터와 서버용 컴퓨터에서 사용하는 파일시스템간의 두드러진 차이점 중의 하나는 각 파일마다 그룹과 소유권을 따로 관리할 수 있다는 점이다. 한 대의 컴퓨터에 여러 명의 사용자가 접근하는 경우 각 사용자들의 파일에 대한 접근 권한을 따로 관리할 필요가 있으며 시스템 관리자의 입장에서도 사용자들이 아무 제재 없이 시스템 파일에 접근하는 것을 막아야 했다.

가까운 예로 윈도 98 계열의 OS를 사용할 때 사용자 계정을 달리하여 로그인 할 수 있었지만, 정작 그들간에 접근할 수 있는 파일에는 제한이 없었다. 이는 FAT 파일시스템에서는 소유권을 관리할 수 없기 때문에 OS 차원에서 제한을 두는 것은 한계가 있기 때문이다. 반대로 NTFS, EXT2를 비롯한 서버급 컴퓨터를 겨냥한 파일시스템은 모든 파일에 사용자 그룹과 소유 권한을 부여할 수 있어서 서로 다른 사용자 파일간의 배타적인 접근이 가능하며, 사용자가 시스템 파일에 허가 없이 접근하는 것을 막을 수 있다.

동기화

현재의 모든 OS들은 멀티태스킹 기능을 지원하여, 하나의 CPU에서도 여러 프로그램이 동시에 실행되는 것처럼 동작한다. 이때 주의해야 할 점이 바로 동기화 작업이다. 하나의 파일에 여러 프로세스가 동시에 접근해서 작업을 하는 경우 해당 파일에 락을 걸어주고 적절한 시점에 해제하는 동기화가 진행되어야 하는데, 파일시스템을 제작하면서 동기화만큼 손이 많이 가는 작업도 드물다. 그만큼 여러가지 상황에 따른 고민을 많이 하며 작업을 해야 하는데, 고민을 하며 작업을 한다 해도 실제로 적용할 때에는 또 다른 상황에서 문제가 생길 수도 있기 때문에 디버깅에도 많은 시간이 할애된다.

간단한 예로 A.TXT라는 파일에 특정 프로세스가 접근해서 읽기를 시도하던 중 다른 프로세스가 해당 파일을 삭제하는 명령을 시도하였다. 만약 파일에 락이 걸려있지 않다면 A.TXT 파일은 삭제되고 파일 읽기 작업을 진행하던 프로세스는 운 좋게 쓰레기 데이터를 읽어 들이고 끝낼 수도 있지만, 파일과 관련된 데이터의 포인터를 통해 찾아가던 중 잘못된 포인터에 접근하여 세그먼테이션 오류를 발생시킬 수도 있다.

게다가 한 대의 컴퓨터에 여러 개의 CPU를 지원하면서 동기화 방법에도 변화가 생기게 되었다. 세마포어 등의 싱글 프로세서 상황에서 적용할 수 있었던 방법을 여러 CPU에 동기화 처리를 적용하기 위해 스핀락으로 교체하는 등의 변화가 생긴 것이다.

최근에 사용되는 파일시스템들은 대부분 파일에 락을 걸 수 있도록 스펙의 정의되어 있다. 락에는 그 유형과 적용해야 하는 위치가 다양하므로 파일시스템을 제작하는 경우에는 각별히 신경 써서 구현하도록 해야 한다.

일관성 체크와 저널링

컴퓨터를 사용하다보면 얘기치 못한 상황에서 시스템이 멈춘다거나 정전이 일어나는 경우가 발생한다. 평상시에는 문제가 되지 않겠지만, 만약 이런 경우에 파일 쓰기를 하고 있었다거나 중요한 업데이트를 하고 있었다면 파일시스템에는 실제 파일이 있는 것처럼 표시되는데 데이터가 잘못될 수 있는 등 일관성이 깨지게 된다.

이런 상황에 대비하여 일관성이 깨지는 것을 최소화할 수 있는 여러 가지 방법이 도입되어야 한다. 가장 우선적으로 파일시스템 구현 시 이러한 상황을 대비해야 하며, 파일을 쓸 때 메타데이터와 파일 데이터를 쓰는 순서부터 시스템 Crash 상황을 고려해야한다. 만약 메타 데이터를 먼저 쓰고 파일 데이터를 나중에 쓰는 경우를 생각하보면 이런 경우 파일 데이터를 쓰는 도중 시스템이 중단되었다면 파일 리스트를 출력할 때에는 파일이 정상적으로 보이지만 막상 데이터를 읽어보면 쓰레기 데이터가 들어가 있을 수도 있다. 반대로 파일 데이터를 먼저 쓰고 메타 데이터를 나중에 쓴다면 파일 데이터를 쓰는 도중 시스템이 멈췄다 하더라도 메타 데이터가 나중에 쓰여지므로 파일 리스트에도 나주이 ㅇ낳으며 해당 파일 데이터가 쓰여진 곳은 어차피 비어 있는 영역이었으므로 나중에 다른 데이터가 쓰여지면 그만이다. 실제로 사용되는 파일시스템들은 이러한 기본적인 순서를 고려하여 작성되었다.

또한 파일시스템의 일관성에 문제가 발생했다고 판된되는 경우를 위한 별도의 유틸리티 프로그램이 요구된다. 대표적으로 FAT, NTFS를 체크하는 chkdsk.exe 나 Ext2를 체크하는 e2fsck 등의 프로그램이 있다. 이러한 프로그램들은 파일시스템 내에 존재하는 모든 메타데이터를 검색하여 문제가 있다고 판단되는 부분을 수정한다. 그런데 문제는 요즘과 같이 하드 디스크의 용량이 수백 GB에 이르는 저장장치의 일관성 체크를 하다보면 몇 시간이 걸릴 수도 있다는 것이다. 당장 서비스를 해야 하는 서버의 경우는 말할 것도 없고, 개인 사용자들도 부팅하기 위해 몇 시간을 기다려야 한다면 진이 빠질 것이다. 이러한 상황을 위해 그 필요성이 대두된 것이 바로 저널링 기능이다.

저널링이란 데이터베이스에서 일관성 체크를 위해 사용되는 방법을 파일시스템에 적용한 것으로서, 파일시스템 업데이트 시(파일을 쓰거나 메타 데이터를 수정하는 경우)에 로그를 기록하고, 문제가 생길 경우 해당 로그를 참조하여 업데이트를 취소할 수도 있고 파일시슽메에 적용 완료 할 수도 있다. 저널링 기능의 가장 큰 장점은 업데이트 로그를 기록 하고 있기 때문에 일관성 체크를 위해 파일시스템의 전 영역을 검색해지 않아도 되며, 해당 로그만 찾아가서 작업을 수행하면 된다는 점이다. 이로써 몇 시간에 걸쳐 진행해야 할 일을 단 몇초 안에 해결할 수 있게 된다.

보안

데이터를 다루는 시스템에서 빠짐없이 등장하는 이슈 중의 한가ㅏ 바로 보안이다. 파일 시스템에도 보안과 관련하여 여러 가지 방법들이 있다. 그 중 간단한 것들은 파일의 소유 권한과 실행 권한등이 있는데 이것은 해당 파일시스템이 이용되고 있는 상황, 즉 OS 등을 통하여 파일시스템에 접근하는 상황에 해당될 뿐이지 그 외에 물리적으로 디스크에 접근하는 경우에는 데이터가 모두 드러나 버리게 된다.

다시 말해 중요한 데이터에 대한 접근 권한을 최소화 하고 로그인 패스워드를 복잡하게 만들었다 해도 하드디스크를 떼어다가 다른 PC 연결하면 그만인 것이다. 설령 다른 PC에서도 파일시스템 차원에서 접근하지 못한다면 디스크를 섹터 단위로 읽어 들여서 파일시스템 규약에 따라 데이터를 분석하면 데이터의 유출은 어쩔 수 없다. 이러한 상황을 위해 파일시스템의 암호화 기법을 도입할 수 있다.

파일시스템의 암호화는 일반적으로 널리 쓰이고 있지는 않지만, 서버급 OS에서 사용되는 파일시스템들은 기본적으로 암호화 기능을 제공하기도 하며, 최근에는 관련 툴이 다양하게 나와 있어 대부분의 OS와 파일시스템에서 암호화를 적용할 수 있다. 암호화를 적용하는 계층은 가상 파일시스템과 파일시스템 자체에서 할 수도 있고 또한 메타 데이터만을 암호화하는 경우와 파일 데이터 영역까지 압축을 통한 암호화를 진행하기도 하며, 디렉토리 및 파일 등을 선택해서 적용할 수도 있다. 이처럼 암호화를 적용하는 상황에 따라 적절하게 범위를 선택하여 진행할 수 있다.