파일시스템 분류

일반적인 파일시스템 

가장 흔히 볼 수 있는 파일시스템은 디스크(플로피디스크, 하드디스크 등)와 같은 저장장치에서 주로 사용된다. 물론 파일시스템은 데이터의 읽고 쓰는 방식을 약속한 것이므로 다른 종류의 저장장치에서도 사용할 수 있지만, 각 저장장치의 특성에 따라 파일시스템의 설계가 틀려지는 것이 보통이다.

예로 하드디스크는 여러 장의 플래터가 회전하며 디스크의 내용을 읽어 들이므로 데이터를 읽어 들이는 속도가 하드디스크의 플래터 회전 속도에 민감하게 반응한다. 또한 랜덤 액세스가 가능하므로 특정 위치의 데이터를 찾아가는 데 필요한 시간이 오래 걸리지는 않지만, 잦은 위치 변경으로 인한 디스크 헤드의 이동 시간 역시 무시할 수 없는 요소이므로 이를 개선하기 위한 파일시스템의 구조 및 세부 알고리즘이 다양하게 적용된다.

FAT(File Allocation Table) 파일시스템

마이크로소프트사의 빌게이츠가 만들었고, 전 세계적으로 가장 많이 사용되는 파일시스템 중 하나이며, 초기에 만들어진 파일시스템이다. 처음 만들어진 이후 여러 번의 발전을 거듭해 왔지만, 최초 제작 당시에는 고려하던 저장장치의 크기가 매우 작았으며 성능상의 문제는 큰 이슈로 작용하지 않았다. 따라서 매우 단순한 구조를 지니고 있으며 최근에는 대용량 저장장치를 지원하기 위해 FAT16, FAT32 등이 만들어진 이후 윈도우 OS의 흥행과 더불어 지금도 널리 사용되고 있다. 이러한 FAT 파일시스템의 범용성은 휴대용 장치들과 PC와의 호환성을 높여주는 결과를 가져왔으며, 이동식 저장장치들은 FAT 파일시스템을 설치하기만 하면 별도의 설치 과정 없이 엔드유저(End User)들의 PC에서 간편하게 읽어 들일 수 있게 만들었다.

파일시스템에서 사용되는 부가 기능은 적고, 제약 사항들은 많은 단점이 있었으나 그만큼 가볍고 심플한 느낌을 갖게 한다. 하지만 그에 따른 여러 문제점들이 생기게 되는데, 연결 리스트를 사용한 자료구조는 검색 시간이 오래 걸리게 하는 결과를 초래하였으며, 파일 데이터 블록들이 여기저기 흩어지는 단편화 현상이 심해져서 한 파일의 데이터를 읽어 들이는 데에도 디스크 헤드가 여러 번 이동하게 만들었다. 이를 위해 디스크 조각 모음 등의 부가적인 프로그램이 등장하기도 하였지만 근본적인 해결책은 되지 않았으며 서버 시스템 등에서 사용되기에는 여러 가지 부족함이 많은 파일시스템이었기에 이후 여러 파일시스템들이 이를 개선하기 위해 등장하게 된다.

HPFS(High Performance FileSystem)

IBM의 OS/2 1.2부터 사용된 파일시스템이며 NTFS가 나오기까지 많은 영향을 준 파일시스템이다. HPFS는 제작당시부터 대용량 디스크에 적합한 구조를 지니고 있었으며, 효율적인 캐싱과 FAT 파일시스템에 비해 파일 손실과 단편화가 적고, 서버 시스템에 사용할 수있도록 여러 가지 보안 기능 등에 대한 요구를 충족시켜 줄 수 있는 파일시스템이다. 대용량 저장장치를 타겟으로 잡았기 때문에 200MB 미만의 저장장치에서는 성능 저하를 가져올 수 있는 단점이 있으며, 섹터 크기가 512Byte로 고정되었기 때문에 기본 데이터 I/O 단위를 변경할 수 없다. 무엇보다 OS/2 가 윈도우 NT와의 경쟁에서 밀려 흥행에 실패하였고, 윈도우 NT 4.0부터는 HPFS를 지원하지 않아 호환조차 불가능했기 때문에 우수한 성능 및 발전 가능성에도 불구하고 비운의 파일시스템이 되었다.

NTFS(New Technology FileSystem)

마이크로소프트사의 서버급 운영체제인 Windows NT에서 사용되는 파일시스템이며, 윈도우 NT 및 2000 이상의 OS에서 대표적인 파일시스템으로 자리 잡아 서버 시스템은 물론 일반 PC에서도 널리 사용되고 있다. NTFS는 대용량 저장장치를 겨냥해서 제작되었으며, 높은 안정성과 부가 기능을 지원하고, FAT와 HPFS에 있던 여러 제약 사항들을 크게 개선한 파일시스템이다. 그러나 제작사인 마이크로소프트사에서 전체 스펙을 공개하지 않아 현재까지도 완벽한 분석이 이루어지지 않았으며, 이로 인해 리눅스 등의 다른 OS에서 NTFS를 지원한다고 해도 미흡한 부분이 있을 수 밖에 없다.

UFS(Unix FileSystem)

UTFS는 유닉스의 대표적인 파일시스템으로서 현재까지 쓰이는 대부분의 유닉스에서 사용되는 파일시스템의 근간이 되었다. BSD 계열(FreeBSD, NetBSD, OpenBSD 등)은 물론이고 HP-UX, Apple OS X, Sun Solaris에 이르기까지 많은 유닉스 계열의 OS들이 UFS를 각각의 OS에 맞게 변형해서 사용하고 있다. UTFS는 빠른 속도와 높은 안정성을 목표로 만들어 졌다. 또한 저장장치를 그룹하하여 관련된 데이터끼리는 최대한 가까운 위치에 자리할 수 있는 구조로 되어 있어 디스크 헤드의 이동이 비교적 적고, 중요한 데이터는 여러 그룹에 걸쳐 많은 백업을 저장하므로 만일의 사태에 대하여 보다 신뢰성을 높였다. UFS는 미국 Berkeley 대학의 FFS(Fast FileSystem)에서 근간을 이루었으며, Bell 연구소에서 Unix Version 을 개발할 때부터 본격적으로 UFS라는 명칭을 사용하였다. UFS는 리눅스 파일시스템인 Ext2에도 큰 영향을 미치게 된다.

Ext2 파일시스템(Second Extended FileSystem)

Ext2 파일시스템은 현재 리눅스의 기본 파일시스템인 Ext3에서 저널링 기능을 뺀 파일시스템으로서 UFS를 근간으로 하고 있다. UFS에서 유명무실한 구조들은 제거하고, 전체적인 구조를 보다 간략히 한 Ext2는 비교적 명료하고 간단하면서도 UFS의 속도와 안정성을 고루 갖춘 파일시스템이다. 그 증거로 Ext2는 현재까지도 리눅스 기본 파일시스템으로 자리 잡고 있는 Ext3에서 그대로 사용되고 있다.

Ext2 파일시스템에서 저널링 기능만을 추가한 것이 Ext3 파일시스템이다.

플래시 파일시스템(Flash FileSystem)

몇 년 전까지만 해도 플래시(Flash) 메모리에 파일시스템을 올리는 것은 사치로 여겼다. 플래시 메모리를 ROM의 일종으로 여겨서 직접 어드레스 단위로 데이터를 Read/Write 하는 것이 일반적이었다. 하지만 요즘에는 임베디드 장치들도 고용량, 고성능이어서 웬만한 PC 못지 않다. 그런 성능 향상에 따라 플래시 메모리를 좀 더 효율적으로 관리하기 위한 플래시 전용 파일시스템의 필요성이 높아졌다. 플래시 파일시스템(Flash FileSystem)의 특징은 플래시 메모리의 특성에 최적화되어 있다는 것이다. 사실 플래시 메모리는 파일시스템을 사용하기가 까다로운 매체이다. 플래시 메모리는 블록(Block) 구조로 되어 있는데 읽는 것은 블록과 관계 없이 바이트 단위로 자유롭지만, 쓰거나 지우는 것은 언제나 블록 단위로 해야만 한다. 이런 블록의 크기는 꽤 큰편이어서 보통 64~128KB까지도 된다. 플래시 메모리의 또 다른 특징은 블록(Block)에 쓰기를 할 수 있는 횟수에 제한이 있다는 점이다.

보통은 10,000 ~ 100,000번 정도를 수명으로 본다. 이 수명은 프래시 메모리의 수명이 아니라 블록의 수명이다. 예를 들어 어떤 플래시 메모리에 블록이 10개 있고 블록의 Write 횟수가 100,000번이라고 하자. 이 플래시 메모리의 블록 하나에 충분히 들어갈 만한 크기의 작은 데이터 하나만 기록한다고 하자.

이럴 경우 블록을 돌려가면서 데이터를 쓰게 된다면 그 플래시 메모리의 수명은 100,000번 X 10블록 = 1,000,000번이 된다. 이것은 중요한 사실이다. 데이터를 블록에 골고루 Write 하는 것은 플래시 파일시스템의 중요한 기능이기 때문이다. 플래시 파일시스템은 임베디드 시스템의 폐쇄성과 맞물려 대중적인 파일시스템이 몇 가지밖에 없다. 임베디드 시스템에 담긴 플래시 메모리의 구조에 호환성은 별로 중요하지 않기 때문에 자체적으로 필요한 구조의 플래시 파일시스템을 구현하여 제품에 올리는 경우가 많다. 하지만 임베디드 리눅스를 제품에 올리게 된다면 아마 JFFS2나 YAFFS 파일시스템을 사용하게 될 것이다.

CD-ROM 파일시스템

디스크뿐만 아니라 CD-ROM 미디어에도 파일시스템이 존재한다. 여러 OS에서 같은 CD를 읽을 수 있는 이유는 표준화되어 있는 CD-ROM 미디어 스펙에 따라서 읽고 쓰기 때문에 가능한 것이다. CD-ROM 파일시스템은 1988년 ISO(International Organization for Standardization, 국제 표준화 기구)에서 ISO 9660 으로 공식 발표되었다. ISO 9660은 디렉토리로 파일을 관리할 수 있도록 되어 있으며, 여러 파일시스템의 요소들이 표준화되어 있어서 서로 다른 디바이스에서도 똑같이 읽어 들일 수 있게 되었다. 이후 ISO 9660은 추가 릴리즈를 하였으며 기존의 것은 ISO 9660 Level 1로 지정되었다. Level 1은 파일명 지정방식이 MS-DOS와 같은 8+3 방식이므로 긴 파일은 사용할 수 없다는 단점이 있다. Level2 2는 파일명을 64Byte 까지 사용 가능하고, DOS에서는 Level 1과 같이(XXXXXX ~ 1.XXX) 보이도록 하위 호환을 지원하는 파일시스템이다. Level 3은 파일명을 128Byte까지 사용할 수 있다. DOS에서는 읽지 못하는 단점이 있으나, 윈도우 등의 OS에서는 정상적으로 읽기가 가능하다.

이 외에도 Microsoft에서 발표한 ISO 9660 표준 확장으로서 유니코드 문자셋이 사용가능한 Joliet 스펙이 있으며, 유닉스 관련 업체들이 결성한 락 릿지 그룹에서 포직스 호환 스펙으로 발표한 Rock Ridge Interchange Protocol 등이 있다.

네트워크 파일시스템

네트워크 파일시스템은 1984년 Sun Microsystems에서 원격에 위치한 파일시스템을 로컬 파일시스템처럼 이요할 수 있도록 개발한 프로토콜이다. 원격지의 파일을 로컬로 가져올 수 있다고 하여 단순히 파일 공유 차원의 것은 아니며 NFS도 결국 파일시스템이라는 것을 인지해야 한다. 따라서 원격 파일시스템이 마운트되면 마운트 지점 아래에 위치한 파일에 접근을 하는 경우 NTFS가 파일시스템 레벨에서 시스템 콜을 받아 직접 네트워크로 파일을 수신하여 로컬 영역에 파일을 쓰거나 직접 실행할 수 있도록 한다. 따라서 로컬 영역에 파일이 존재하지 않더라도 원격지 프로그램의 실행이 가능하며, 그 프로그램과 관련된 다른 파일들도 자동으로 연결된다.

NTFS의 초기 버전에서는 UDP 통신만 가능했으나 이후에는 TCP도 지원하며, 파일 크기를 64Bit까지 지원하여 4GB가 넘는 파일도 NFS로 이용 가능하게 되었다.

가상 파일시스템

PC를 사용하다보면 하나의 OS에서 여러 개의 파일시스템에 접근해야 할 경우가 종종 있다.

최근의 윈도우 OS의 경우 FAT32 파일시스템 위에 OS가 설치되어 있다고 하더라도 별도의 설정 없이도 다른 파티션에 있는 NTFS를 읽고 쓸 수 있다. 또한 리눅스의 경우 지원하는 파일 시스템의 종류를 보면 10여 가지에 달한다. 이것은 OS 차원에서 가상 파일시스템(Virtual FileSystem)이라는 상위 레벨의 파일시스템 인터페이스가 존재하기 때문에 응용프로그램에서는 아무 구분 없이 OS의 시스템 콜을 호출하면 커널은 미리 등록되어 있는 파일시스템 함수를 호출하여 그 종류에 상관없이 같은 결과를 볼 수 있다. 만약 가상 파일시스템이 없다면 일단 OS를 설치하고 나면 다른 파일시스템이 설치된 파티션을 인식할 수 없을 뿐만 아니라 다른 파일시스템의 인식을 위해서 별도로 컴파일된 파일시스템 모듈을 덮어 씌워야 할 것이다.

위 그림은 가상 파일시스템과 일반 파일시스템의 레이어 구조를 나타낸 것이다. 가상 파일 시스템은 로컬 영역이나 원격 영역의 파일시스템을 실제로 제어하지 않기 때문에 OS 부팅 시에 사용 가능한 파일시스템 함수를 가상 파일시스템 쪽으로 등록해 주어야 한다. 일반적으로 하드디스크에서 사용하는 파일시스템뿐만 아니라 CD-ROM 파일시스템과 네트워크 파일시스템 등 기본적으로 등록하는 파일시스템이 여러 가지 있다.

가상 파일시스템의 아이디어가 최초 적용된 OS는 1986년 Sun Microsystems의 SunOS 2.0이다.

당시 SunOS에서 로컬 영역의 UFS와 Remote 영역의 NFS를 동시에 지원하면서 그 개념이 도입되었고, 이후 대부분의 유닉스 계열의 OS들이 가상 파일시스템을 지원하였다.