반응형
파일 시스템의 이해
파일 시스템의 개요
- 파일 시스템이란 디스크에 사용자의 데이터를 효율적으로 저장하기 위한 파일과 디렉터리를 조직화한 체계
- 디스크에 포맷 작업을 한다는 의미는 빈 종이에 글씨 쓰기 좋게 줄을 긋는 것과 비슷하다. 포맷은 디스크를 일정한 크기로 분할하고 주소를 설정하여 사용자의 자료를 조직적으로 보관할 수 있게 한다.
- 사용자의 데이터는 파일 단위로 관리가 되며 디스크에 저장할 때에는 레코드 단위 혹은 블록 단위로 저장된다. 각 파일은 디렉터리에 속하여 그룹을 생성할 수 있어 많은 파일을 체계적으로 관리할 수 있다.
- 파일 시스템은 파일 입출력 시 발생하는 오류에 대하여 복구할 수 있는 기능도 제공한다.
- 디스크 입출력은 메모리에 비해 속도가 느리기 때문에 파일 시스템은 캐시 기능을 제공하여 디스크의 입출력을 최소화한다.
리눅스 파일 시스템의 구조
ext2의 파일 시스템
- ext3와 ext4는 모두 ext2를 근간으로 발전했다. ext2 파일 시스템의 구조를 이해하면 리눅스 파일 시스템이 어떻게 파일을 조직화하고 관리하는지 이해할 수 있다.
부트 섹터(boot sector)와 블록 그룹(block group)
- ext2 파일 시스템은 부트 섹터와 그에 뒤따르는 여러 개의 블록 그룹들로 구성된다.
- 블록 그룹은 모두 같은 블록 개수를 가진다. 단, 마지막 블록 그룹은 예외이다.
블록 그룹
- 블록 그룹은 여러 개의 블록으로 구성된다. 한 파일이 여러 블록에 나누어서 저장되어야 하는 경우 단편화를 최소화하기 위해 동일 블록 그룹에 위치하려고 스케줄링한다.
- 블록 그룹은 슈퍼 블록(super block), 그룹 디스크립터 테이블(group descriptor table), 블록 비트맵(block bitmap), 아이노드(i-node) 그리고 실제 사용자의 데이터를 담고 있는 블록(block)으로 구성된다.
- 슈퍼 블록과 그룹 디스크립터 테이블은 0번 블록 그룹에만 포함되어도 기능상 문제가 없으나 손상이 되면 파일 시스템 접근이 불가능하므로 다른 블록 그룹에도 사본이 보관되어 있다.
- 블록 비트맵은 그룹 내의 각 블록이 할당되어 있는지 여부를 비트(bit)로 표현한다. 즉 4KB 크기의 블록이라면 한 바이트는 8개의 비트로 구성되므로 총 32,768개의 블록 할당 여부를 표현할 수 있다.
슈퍼 블록(super block)
- 파일 시스템의 전체 내용을 담고 있는 블록으로 1KB만 사용한다. 즉 4KB의 블록을 사용하더라도 1KB만 사용하고 나머지 3KB는 비워 둔다.
- 슈퍼 블록에는 블록의 크기, 총 블록의 개수, 블록 그룹의 개수, 아이노드의 개수, 그룹 내 블록의 개수, 그룹 내 아이노드의 개수 등에 대한 정보가 포함된다.
그룹 디스크립터 테이블(group descriptor table)
- 블록 그룹에 대한 정보를 담고 있으며 32byte 크기인 그룹 디스크립터의 목록이다. 만약, 블록 크기가 1KB라면 총 32개의 그룹 디스크립터가 포함될 수 있다.
- 그룹 디스크립터 테이블은 블록 비트맵의 블록번호, 아이노드 비트맵의 블록 번호, 첫 번째 노드 테이블의 블록 번호, 그룹 안에 있는 빈 블록 수, 그룹 안에 있는 아이노드 수, 그룹 안에 있는 빈 디렉터리 수이다.
블록 비트맵(block bitmap)
- 블록 비트맵은 블록의 할당 여부를 비트로 표현한다. 각 비트에 해당하는 블록이 사용 중이면 1, 아니면 0으로 나타낸다.
아이노드 비트맵(i-node bitmap)
- 아이노드의 할당 여부를 비트로 나타낸다.
아이노드 테이블(i-node table)
- 단일 블록이 아닌 연속된 블록으로 이루어져 있으며 각 블록은 미리 정의된 아이노드 개수를 포함한다.
- 아이노드의 첫 번째 블록의 번호를 그룹 디스크립터 테이블에 저장한다.
- 모든 아이노드의 크기는 128바이트로 동일하다. 예를 들어 아이노드 테이블 블록이 1,024byte라면 아이노드를 8개 포함할 수 있다.
아이노드(i-node)
- 아이노드는 실제 파일과 디렉터리의 데이터 위치를 알고 있는 자료구조이다.
- 아이노드는 Inode Number, 파일 모드, 하드링크 수, 소유자 ID, 파일 크기, 마지막 접근, 마지막 수정, Inode 수정, 데이터 블록 수의 정보를 가지고 있다.
- 모든 파일과 디렉터리는 각 1개의 아이노드를 가지고 있고 고유한 주소를 가지고 있다.
- 아이노드의 주소를 알고 있다면 해당 아이노드가 가리키는 블록 그룹을 찾아갈 수 있다.
- 아이노드 1번은 슈퍼 블록, 2번은 루트 디렉터리 등 10번까지는 예약되어 있다.
- 아이노드 번호를 안다면 아이노드 테이블에서 해당 아이노드를 찾아 실제 파일을 찾아갈 수 있다.
ext2 내부 구조
- 15개의 포인터가 있는 구조이다.
- 그중 처음부터 12번까지는 직접 블록을 위한 것이다.
- 13번 포인터는 간접 블록을, 14번째 블록은 이중 간접 블록을, 15번째 포인터는 삼중 간접 블록을 가리킨다.
리눅스 로컬 파일 시스템(Local Filesystems)
ext
- minix 파일 시스템을 개선하기 위해 레미 카드(Remy Card)는 최대 2기가 파티션과 255까지의 파일명을 지원하는 ext 파일 시스템을 개발했다.
- 파일 접근에 대한 타임스탬프 기능, 아이노드 수정 기능의 부재와 조각화 이슈가 있었다.
ext2
- ext의 한계를 극복하기 위해 만들어졌다.
- 타임스탬프 기능, 아이노드 수정 기능, 쓰면 쓸수록 느려지는 조각화 이슈를 해결했다.
- 파일 시스템에 데이터를 쓰는 동안 전원이 끊어지면 데이터가 제대로 저장되지 않는 문제가 있다. 문제가 발생하면 관리자는 fsck 명령어를 사용해서 복구한다.
- 파일 시스템의 크기는 블록 단위에 따라 2TiB~32TiB이다.
- 파일 크기도 블록 단위에 따라 16GiB~2TiB이다.
ext3
- 커널 2.4.15부터 포함된 리눅스 대표 저널링 파일 시스템이다.
- 파일 시스템에 데이터를 쓰는 동안 전원이 끊어지더라도 복구할 수 있는 기능을 제공하기 위해 로그를 통해 파일 시스템을 복구하는 저널링 기술을 채용했다.
- 저널링에는 저널 모드(journal mode), 순서 모드(ordered mode), 쓰기 저장(writeback mode) 모드가 있다.
- 온라인 파일 시스템 증대, 큰 디렉터리를 위한 HTree 인덱싱 기능, ACL을 통한 접근 제어를 제공한다.
- 단점으로는 온라인 조각모음 프로그램이 없다.
- ext2와 마찬가지로 최대 파일 크기는 16GiB~2TiB이고, 최대 파일 시스템 크기는 2TiB~32TiB이다.
ext4
- ext2와 ext3를 호환하면서 기능을 확장했으며 48비트 블록 주소 지정을 통해 1EiB까지 디스크 볼륨과 16TiB까지의 파일을 지원한다.
- 큰 파일 처리를 개선하고 단편화 현상을 줄이기 위해 ext2, ext3의 간접 블록 매핑(indirect block mapping) 방식 대신 Extents 방식을 사용한다. 간접 블록 매핑 방식은 하나의 블록을 가리키기 위해 하나의 엔트리로 여러 블록을 가리킬 수 있게 된다.
- ext2, ext3를 ext4 방식으로 마운트하여 성능이 향상된 상태로 사용할 수 있으며, ext4는 ext3 방식으로 마운트될 수 있다. 그러나 Extents를 사용하는 ext4 파티션은 ext3 방식으로 마운트될 수 없다.
- 파일 시스템 손상 가능성을 줄여주는 저널 체크섬 기능을 제공한다.
- ext3의 32,000개 서브 디렉터리 제약을 극복하고 64,000개로 늘어났다.
- XFS, ZFS, btrfs, Reiser4와 같은 현대 파일 시스템에서 사용되는 지연된 할당 기능(Delayed allocation)을 제공한다. 이는 프로세스가 write를 호출하더라도 즉시 디스크에 블록을 할당하지 않고 캐시에 보관하는 것이다. 이는 디스크에 대한 I/O를 최소화하고 mballoc 할당자를 통해 한 번에 여러 블록을 할당할 수 있기에 성능 개선이 된다.
- ext3의 블록 할당자는 한 시점에 하나의 블록(4KiB)만 할당할 수 있으나, ext4는 여러 블록을 동시에 할당할 수 있는 멀티 블록을 할당할 수 있기에 성능 개선에 도움이 되며 지연 할당과 Extents를 동시에 사용할 때 더욱 성능 개선 효과가 크다.
- 나노초 단위의 파일 스탬프를 제공한다.
- ext2, ext3, ext4의 매직넘버는 0xEF53이다.
btrFS
- 2007년 오라클에서 재직 중이던 크리스 메이슨이 개발한 B-Tree 파일 시스템이다.
- 전체 파일 시스템이 아닌 특정 파일, 볼륨, 하위 볼륨의 스냅샷 찍기 기능을 제공한다.
- 저렴한 디스크의 RAID를 제공한다.
- 역참조는 파일 시스템 개체에 I/O 오류를 매핑한다.
- 자동 압축 기능을 제공한다.
- 데이터 및 메타 데이터의 체크섬을 제공한다.
ZFS
- 유닉스의 파일 시스템을 대체하기 위해 SUN에서 개발한 파일 시스템으로 Solaris 10에서 소개됐다.
- 단순한 파일 시스템을 넘어 볼륨 매니저 역할까지 수행한다.
- 단일 파일 시스템에 여러 개의 개별 저장장치를 처리하는 볼륨 관리 기능, 블록 수준 암호화, 데이터 손상 탐지 기능, 자동 손상 복구, 신속한 비동기 증분 복제, 인라인 압축 등 많은 기능을 제공한다.
Reiserfs
- 독일의 한스 라이저가 개발한 저널링 파일 시스템이다.
- 커널 2.4.1에 포함되었다.
XFS
- 1993년 실리콘 그래픽스가 만든 고성능 64비트 저널링 파일 시스템으로 커널 2.4.20에 포함됐다.
- 64파일 시스템이며 최대 파일 시스템의 크기는 8EiB -1이다. 하지만 32비트 리눅스 시스템의 경우 파일과 파일 시스템의 최대 크기를 모두 16TiB로 제한하고 있다.
- Extents 기반 할당을 사용하며 조각화를 줄이면서 성능 향상을 위한 사전 할당(explicit pre-allocation) 및 지연 할당(delayed allocation) 등과 같은 다양한 할당 방법을 제공한다.
- 빠른 복구를 가능하게 하는 메타데이터 저널링(metadata journaling)을 제공한다.
- 마운트가 활성화되어 있는 상태에서도 조각 모음이 가능하고 볼륨의 확장이 가능하다.
- XFS는 b-트리 알고리즘을 사용하여 모든 사용자 데이터 및 메타데이터를 인덱스하여 우수한 I/O 확장성을 제공한다.
JFS
- IBM에 의해 개발한 64bit 저널링 파일 시스템으로 커널 2.4.24에 포함됐다.
클러스터 파일 시스템(Clustered Filesystems)
Raw Partitions
- 파일 시스템이 설정되어 있지 않은 상태를 뜻한다.
- 운영체제의 버퍼 캐시를 사용하지 않으므로 고성능의 입출력이 가능하다.
- 파일 시스템을 통하는 오버헤드가 없다.
- 파일 시스템을 이용하지 않기 때문에 숙련된 관리자의 관리가 필요하다.
Oracle Cluster FilesSystem(OCFS)
- Raw Partition의 다루기 힘든 문제를 해결하면서 RAC(Real Application Cluster)의 사용 목적을 위해 설계된 파일 시스템이다.
- Raw Partition보다 단지 2~5% 정도 속도가 느린 것으로 알려져 있다.
- OCFS의 다음 버전인 OCFS2는 POSIX를 호환하는 범용 클러스터 파일 시스템으로 개발됐다.
기타 리눅스 파일 시스템
minix
- 1987년 앤드류 태넌바움(Andrew Tannenbaum)이 교육 목적으로 minix 운영체제를 개발했고 minix 파일 시스템이 포함됐다. Tannenbaum의 책을 구입하면 69달러에 소스코드까지 구매할 수 있었다.
- 토발즈도 초기 리눅스 개발 시 minix를 파일 시스템으로 채용했다.
- 파티션 사이즈가 64MB 제한이 있고 파일 이름도 14까지 지원한다.
- 단일 타임스탬프를 사용한다.
xiafs
- minix 파일 시스템의 기초가 되었고 프랭크 시아(Frank Xia)가 개발한 리눅스 커널을 위한 파일 시스템이다.
vfat
- 마이크로소프트의 FAT32 파일 시스템 호환을 목적으로 개발한 파일 시스템이다.
isofs
- ISO 기준을 따르는 표준 CD-ROM 파일 시스템이다.
nfs
- 네트워크 상에서 파일 시스템을 공유하기 위한 파일 시스템이다.
proc
- 프로세스 등 커널의 정보를 표현하는 리눅스의 가상 파일 시스템이다.
smb
- SMB 프로토콜을 지원하는 네트워크 파일 시스템으로 최근 CIFS로 확장됐다.
반응형
'Linux > 리눅스 실무의 이해' 카테고리의 다른 글
02-04-01 셸(Shell) (0) | 2022.01.17 |
---|---|
02-03 X 윈도우 (0) | 2022.01.15 |
02-02-02 Systemd (0) | 2022.01.12 |
02-02-01 리눅스의 구조 (0) | 2022.01.11 |
02-01 리눅스와 하드웨어 (0) | 2022.01.11 |