CentOS의 저널링 파일 시스템 ext3에 대한 심층 분석-리눅스-php.cn

개요

1. 로그 파일 시스템

2. ext3의 장점

3, ext3의 세 가지 로그 모드

4. 로그 모드를 선택하세요

1. 로그 파일 시스템

보통 시스템이 실행되는 동안 파일 내용이 기록될 때 파일의 메타데이터(예: 권한, 소유자, 생성 및 액세스 시간)는 기록되지 않습니다. 시스템이 비정상적으로 종료되면 쓰기 프로세스의 파일 시스템이 비정상적으로 언로드되어 파일 시스템이 일관성이 없는 상태가 됩니다. 재부팅할 때 Linux는 fsck 프로그램을 실행하여 전체 파일 시스템을 검사하여 모든 파일 블록이 올바르게 할당 또는 사용되었는지 확인하고 손상된 디렉터리 항목을 찾아 복구를 시도합니다. 그러나 fsck는 손상 복구를 보장하지 않습니다. 이런 일이 발생하면 파일의 일관성 없는 메타데이터가 손실된 파일의 공간을 채우게 되고 디렉터리 항목의 파일 항목이 손실되어 파일이 손실될 수 있습니다.

파일 시스템의 불일치를 최소화하고 운영 체제의 시작 시간을 단축하기 위해 파일 시스템은 시스템 변경을 일으키는 기록을 추적해야 합니다. 이러한 기록은 일반적으로 파일 시스템이라고 불리는 별도의 장소에 저장됩니다. "로그". 이러한 로그 레코드가 안전하게 기록되면 로그 파일 시스템은 이를 사용하여 시스템 변경을 유발한 레코드를 정리하고 파일 시스템 변경을 유발한 레코드 집합을 형성하여 데이터베이스 트랜잭션에 배치하고 상태를 유지할 수 있습니다. . 유효한 데이터의 정상적인 작동은 전체 시스템의 성능과 충돌하지 않습니다. 시스템 충돌이 발생하거나 다시 시작해야 하는 경우 로그 파일에 기록된 정보에 따라 데이터가 복원됩니다. 로그 파일에는 정기적인 체크포인트가 있으므로 일반적으로 매우 깔끔합니다. 파일 시스템 설계에서는 주로 효율성과 성능 문제를 고려합니다.

Linux는 FAT, VFAT, HPFS(OS/2), NTFS(Windows NT), UFS, XFS, JFS, ReiserFS, ext2, ext3 등을 포함한 다양한 로그 파일 시스템을 지원할 수 있습니다.

2. ext3의 장점

ext2에서 ext3로 마이그레이션해야 하는 이유는 무엇입니까? 가용성, 데이터 무결성, 속도, 마이그레이션 용이성이라는 네 가지 주요 이유가 있습니다.

가용성

비정상적인 충돌(정전, 시스템 충돌) 발생 후 ext2 파일 시스템은 e2fsck를 통한 일관성 검증 후에만 마운트 및 사용이 가능합니다. e2fsck 실행 시간은 주로 ext2 파일 시스템의 크기에 따라 달라집니다. 약간 큰 파일 시스템(수십 기가바이트)을 확인하는 데는 시간이 오래 걸립니다. 파일 시스템에 파일이 많으면 확인 시간이 더 오래 걸립니다. 수백 기가바이트의 파일 시스템을 확인하는 데는 한 시간 이상이 걸릴 수 있습니다. 이는 유용성을 크게 제한합니다. 반면, 하드웨어 장애가 발생하지 않는 한 ext3는 비정상적으로 종료되더라도 파일 시스템 확인이 필요하지 않습니다. 이는 파일 시스템 전체에서 일관된 방식으로 데이터가 디스크에 기록되기 때문입니다. 비정상 종료 후 ext3 파일 시스템을 복원하는 시간은 파일 시스템의 크기나 파일 수에 따라 달라지지 않고 일관성을 유지하는 데 필요한 "로그"의 크기에 따라 달라집니다. 기본 로그 설정을 사용하면 복구 시간은 단 1초입니다(하드웨어 속도에 따라 다름).

데이터 무결성

ext3 파일 시스템을 사용하여 비정상 종료 시 데이터 무결성 성능이 안정적으로 보장됩니다. 데이터 보호 유형과 수준을 선택할 수 있습니다. 파일 시스템을 일관성 있게 유지하도록 선택할 수 있지만 비정상적인 종료 중에 파일 시스템의 데이터가 손상되도록 허용하면 일부 상황에서 속도가 어느 정도 향상될 수 있습니다(모든 상황은 아님). 파일 시스템과 일관되게 데이터 안정성을 유지하도록 선택할 수도 있습니다. 즉, 충돌 후 새로 작성된 파일에 데이터 쓰레기가 표시되지 않습니다. 파일 시스템과 일치하는 데이터 무결성을 유지하는 이 안전 옵션이 기본 설정입니다.

속도

ext3은 ext2보다 데이터를 더 많이 쓰지만 ext2보다 빠른 경우가 많습니다(높은 데이터 흐름). 이는 ext3의 로깅 기능이 하드디스크 헤드의 회전을 최적화하기 때문이다. 3가지 로깅 모드 중 하나를 선택하여 속도를 최적화하고 일부 데이터 무결성을 선택적으로 희생할 수 있습니다. 첫 번째 모드인 data=writeback은 제한된 데이터 무결성을 보장하고 충돌 후 오래된 데이터가 파일에 존재할 수 있도록 허용합니다. 이 모드는 특정 상황에서 속도를 향상시킬 수 있습니다. (대부분의 저널링 파일 시스템에서 이 모드는 기본 설정입니다. 이 모드는 ext2 파일 시스템에 대해 제한된 데이터 무결성을 제공하며 시스템 시작 시 긴 파일 시스템 확인을 피하기 위한 것입니다.) 두 번째 이 모드는 data = orderd(기본값) 모드)는 파일 시스템과 데이터 안정성을 일관되게 유지합니다. 즉, 충돌 후 새로 작성된 파일에 정크 데이터가 표시되지 않습니다. 세 번째 모드인 data=journal은 대부분의 경우 적당한 속도를 보장하기 위해 더 큰 저널이 필요합니다. 또한 충돌 후 복구하는 데 시간이 더 오래 걸립니다. 그러나 일부 데이터베이스 작업에서는 더 빠릅니다. 일반적인 상황에서는 기본 모드를 사용하는 것이 좋습니다. 모드를 변경해야 하는 경우 /etc/fstab 파일의 해당 파일 시스템에 data=mode 옵션을 추가하세요. 자세한 내용은 mount 명령(man mount 실행)의 맨페이지 온라인 매뉴얼을 참조하십시오.

마이그레이션이 쉬움

하드 드라이브를 다시 포맷하지 않고도 ext2에서 ext3으로 쉽게 마이그레이션할 수 있으며 안정적인 저널링 파일 시스템의 이점을 누릴 수 있습니다. 예, 길고 지루하며 오류가 발생하기 쉬운 "백업-재포맷-복원" 작업을 수행하지 않고도 ext3의 장점을 경험할 수 있습니다. 마이그레이션 방법에는 두 가지가 있습니다:

시스템을 업그레이드하는 경우 Red Hat Linux 설치 프로그램이 마이그레이션을 지원합니다. 각 파일 시스템에 대해 선택 버튼을 클릭하기만 하면 됩니다.

tune2fs 프로그램을 사용하여 기존 ext2 파일 시스템에 로깅 기능을 추가합니다. 변환 프로세스 중에 파일 시스템이 마운트된 경우 ".journal" 파일이 루트 디렉터리에 표시됩니다. 파일 시스템이 마운트되지 않은 경우 해당 파일은 파일 시스템에 표시되지 않습니다. 파일 시스템을 변환하려면 tune2fs –j /dev/hda1(또는 변환하려는 파일 시스템이 있는 장치 이름)을 실행하고 /etc/fstab 파일의 ext2를 ext3으로 변경하면 됩니다. 자신의 루트 파일 시스템을 변환하려면 initrd를 사용하여 부팅해야 합니다. mkinitrd의 수동 설명에 따라 프로그램을 실행하고 initrd가 LILO 또는 GRUB 구성에 로드되었는지 확인합니다. 성공하지 못하면 시스템은 계속 시작할 수 있지만 루트 파일 시스템은 ext3 대신 ext2로 로드됩니다. 이를 확인하려면 cat / proc/mounts 명령을 사용할 수 있습니다.) 자세한 내용은 tune2fs 명령(man tune2fs 실행)에 대한 매뉴얼 페이지 온라인 매뉴얼을 참조하세요.

3, ext3의 세 가지 로그 모드

Ext3는 다중 로그 모드를 제공합니다. 즉, 파일 시스템의 메타데이터를 변경하든 파일 시스템의 데이터를 변경하든(파일 자체에 대한 변경 포함) ext3 파일 시스템은 /를 활성화할 때 이를 지원할 수 있습니다. etc/fstab 파일이 부팅되었습니다. 세 가지 로그 모드:

data=일지 로그 모드

로그 기록에는 파일 시스템을 변경한 모든 데이터와 메타데이터가 포함됩니다. 세 가지 ext3 저널링 모드 중 가장 느리지만 오류 가능성을 최소화합니다. "data=journal" 모드를 사용하려면 ext3에서 각 변경 사항을 파일 시스템에 두 번, 저널에 한 번 기록해야 하므로 파일 시스템의 전체 성능이 저하됩니다. 모든 새 데이터는 먼저 로그에 기록된 다음 위치를 찾습니다. 사고가 발생한 후 로그를 재생하여 데이터와 메타데이터를 일관된 상태로 되돌릴 수 있습니다. ext3의 메타데이터 및 데이터 업데이트가 기록되므로 이러한 로그는 시스템이 다시 시작될 때 적용됩니다.

data=순서화된 로그 모드(기본값)

변경된 파일 시스템의 메타데이터만 기록되며 오버플로 파일 데이터는 디스크에 추가되어야 합니다. 이것이 기본 ext3 로깅 모드입니다. 이 모드는 파일 시스템에 쓰는 것과 로그에 쓰는 것 사이의 중복을 줄여 속도가 더 빠릅니다. 비록 파일 데이터의 변경 사항이 로그에 기록되지는 않지만 ext3 데몬 프로그램에 의해 실행되어야 하고 실행됩니다. 즉, 메타데이터를 기록하기 전에 파일 시스템 데이터를 수정해야 합니다. 이렇게 하면 시스템 성능(속도)이 약간 떨어지지만 파일 시스템의 파일 데이터가 해당 파일 시스템.

data=쓰기 저장 로그 모드

파일 시스템 변경 사항의 메타데이터만 기록합니다. 그러나 표준 파일 시스템에 따르면 쓰기 프로그램은 파일 시스템 일관성을 유지하기 위해 여전히 디스크의 파일 데이터 변경 사항을 기록해야 합니다. 이는 가장 빠른 ext3 저널링 모드입니다. 파일 크기, 디렉터리 정보 등 파일 데이터와 관련된 업데이트를 기다리지 않고 메타데이터 변경 사항만 기록하기 때문에 파일 데이터 업데이트와 메타데이터 변경 사항 기록이 비동기식으로 이루어질 수 있습니다. 즉, ext3은 비동기 로그를 지원합니다. 문제는 시스템이 종료되면 업데이트된 데이터가 디스크에 기록될 수 없기 때문에 일관성이 없다는 것입니다. 이 문제는 아직 해결되지 않았습니다.

로그 모드마다 차이가 있지만 설정 방법은 동일하고 편리합니다. 로그 모드는 시작 시 /etc/fstab에 의해 수행되는 ext3 파일 시스템을 사용하여 지정할 수 있습니다. 예를 들어 data=writeback 로그 모드를 선택하면 다음 설정을 지정할 수 있습니다.

/dev/hda5 /opt ext3 데이터=쓰기 저장 1 0

일반적인 상황에서는 data=ordered 로그 모드가 ext3 파일 시스템의 기본 모드입니다.

로깅 방법을 지정하려면 다음 방법을 사용할 수 있습니다.

1 /etc/fstab의 옵션 필드에 data=journal

과 같은 적절한 문자열을 추가합니다.

# /dev/sda3 /var ext3 기본값, 데이터=쓰기 저장 1 2

2 마운트 호출 시 -o data=journal 명령줄 옵션을 직접 지정합니다.

# mount -o 데이터=journal /dev/sdb1 /mnt

특정 파일 시스템의 로그 모드를 확인하려면 dmesg 명령을 통해 어떻게 쿼리할 수 있습니까?

# dmesg | grep -B 1 "마운트된 파일 시스템"

kjournald 시작 간격 5초

EXT3-fs: 정렬된 데이터 모드로 마운트된 파일 시스템.

Sda1의 EXT3 FS, 내부 저널

EXT3-fs: 정렬된 데이터 모드로 마운트된 파일 시스템.

sdb1의 EXT3 FS, 내부 저널

EXT3-fs: 저널 데이터 모드로 마운트된 파일 시스템.

sdb1의 EXT3 FS, 내부 저널

EXT3-fs: 쓰기 저장 데이터 모드로 마운트된 파일 시스템.

4. 로그 모드를 선택하세요

속도

일부 일반적인 경우 data=writeback 옵션을 사용하면 속도가 크게 향상되지만 동시에 데이터 일관성 보호가 저하됩니다. 이러한 경우 데이터 일관성 보호는 정상 작동 중에 시스템이 지속적으로 파일 시스템 무결성을 유지한다는 점을 제외하면 기본적으로 ext2 파일 시스템과 동일합니다(이것은 다른 저널링 파일 시스템에서 사용되는 저널링 모드입니다). 여기에는 빈번한 공유 쓰기 작업뿐만 아니라 대량의 작은 이메일 메시지 전송과 같이 대량의 작은 파일을 자주 생성 및 삭제하는 것도 포함됩니다. ext2에서 ext3으로 전환하고 애플리케이션 성능이 크게 저하되는 경우 data=writeback 옵션을 사용하면 성능을 향상하는 데 도움이 될 수 있습니다. 값비싼 데이터 일관성 보호 조치를 취하지 않더라도 ext3의 이점을 계속 누릴 수 있습니다(파일 시스템은 항상 일관성이 있음). Red Hat은 여전히 ext3 성능의 일부 측면을 개선하기 위한 작업을 진행 중이므로 향후 ext3 성능의 일부 측면이 개선될 수 있습니다. 이는 또한 지금 data=writeback을 선택하더라도 기본값인 data=journal을 사용하여 향후 버전을 다시 테스트하여 새 버전의 변경 사항이 작업과 관련이 있는지 확인해야 함을 의미합니다.

데이터 무결성

대부분의 경우 사용자는 파일 끝에 데이터를 씁니다. 데이터베이스와 같은 일부 경우에만 사용자가 기존 파일 중간에 데이터를 씁니다. 기존 파일을 덮어쓰는 경우에도 먼저 파일을 잘라낸 다음 파일 끝에서 데이터를 쓰면 됩니다. data=ordered 모드에서 파일을 쓰는 동안 시스템이 충돌하면 데이터 블록을 부분적으로 덮어쓸 수 있지만 쓰기 프로세스가 완료되지 않으므로 시스템에는 어떤 파일에도 속하지 않는 불완전한 데이터 블록이 있습니다. data=ordered 모드에서 충돌 후 정렬되지 않은 데이터 블록이 남아 있는 유일한 상황은 프로그램이 충돌 중에 파일을 다시 쓰는 경우입니다. 이 경우 프로그램이 fsync() 및 O_SYNC를 사용하여 쓰기가 특정 순서로 발생하도록 강제하지 않는 한 쓰기 순서가 절대적으로 보장되지 않습니다.

ext3 파일 시스템에는 캐시의 데이터를 하드 디스크로 플러시하는 방법도 포함됩니다. kupdate 프로세스를 통해 정기적인 플러시를 구현합니다. 기본적으로 5초마다 확인하여 30초를 초과하는 더티 데이터를 하드 디스크로 플러시합니다.

3.0에서는 /proc/sys/vm/bdflush를 수정하여 목적을 달성할 수 있습니다. 4.0에서는 /proc/sys/vm/dirty_writeback_centisecs 및 /proc/sys/vm/dirty_expire_centisecs를 수정하여 목적을 달성할 수 있습니다.

기본값은 Ordered 모드이므로 이 모드에서는 IO가 데이터 파일을 먼저 쓴 다음 로그 파일을 쓰는 경우입니다. 데이터 파일을 작성한 후 로그 파일을 작성하기 전에 시스템이 충돌하면 데이터의 이 부분이 손실됩니다. 이는 Oracle이든 MySQL이든 데이터베이스에서 절대 허용되지 않습니다. 따라서 데이터베이스 쓰기의 경우 각 쓰기 작업은 먼저 페이지 캐시에 기록된 다음 커널 스레드에 알림을 보내 버퍼를 하드 디스크에 플러시한 다음 메타데이터가 로그에 기록되고 마지막으로 성공적인 쓰기 작업이 이루어집니다. 반환됩니다. 이러한 방식으로 데이터베이스에 대한 쓰기 작업은 베어 장치에 쓰는 것만큼 빠르지 않습니다.

그래서 Ext3를 사용하여 데이터베이스를 실행할 때 로그 모드를 저널 모드로 설정하면 성능이 향상되어야 합니다(아직 테스트되지 않았으므로 이론적 분석은 이렇습니다). 저널 모드에서는 데이터베이스 쓰기 작업의 경우 데이터 및 파일 시스템 변경 사항이 먼저 로그에 직접 기록되고(직접 쓰기는 성능이 더 나은 캐시를 우회함) 데이터가 캐시에 기록된 다음 kupdate 프로세스는 하드 드라이브의 데이터를 새로 고칩니다. 반면 DB의 경우 이전보다 성능이 빨라져야 합니다.

또한 MySQL의 sync_binlog 매개변수는 다음과 같습니다. 이 매개변수가 1로 설정되면 binlog 파일이 기록될 때마다 Oracle의 IO 쓰기와 마찬가지로 동시에 하드 디스크로 플러시된다는 의미입니다. 이 매개변수가 꺼지면 OS에서 관리합니다. 즉, 5초마다 확인하여 30초 전의 오래된 데이터가 발견되면 하드 디스크로 플러시됩니다. innodb_flush_log_at_trx_commit 매개변수에는 하드 디스크 플러시 문제도 포함됩니다.

Ext2의 향상된 버전인 Ext3은 ext2에서 사용되는 수퍼블록, inode, 그룹 설명자 및 기타 데이터 구조와 거의 동일하므로 ext3은 ext2와 향후 호환됩니다. ext2 파일 시스템 데이터를 백업하지 않고 다음을 사용할 수 있습니다.

# tune2fs –j/dev/sd1

파티션을 마운트 해제하지 않고 ext2 파일 시스템을 ext3 파일 시스템으로 직접 변환합니다.

파일을 편집할 때 갑자기 정전이 발생하거나 시스템이 잠겨 강제로 다시 시작된다고 가정해 보세요. 결과는 어떻게 될까요? 최악의 경우 파일 내용의 일부가 손실되고, 최악의 경우 파일 내용 전체가 엉망이 되며, 심지어 파일 시스템이 직접 충돌하는 경우도 있습니다. 이건 정말 끔찍한 일이겠죠. Linux가 정상적으로 종료되면 파일 시스템을 제거한다는 인쇄 메시지가 표시됩니다. 비정상적인 종료로 인해 파일 시스템에 불일치가 발생합니다. 이 불일치는 시스템 재시작 단계에서 파일 시스템이 마운트될 때 발견됩니다. 그것을 수리해 보세요. 불행하게도 저장 장치의 용량이 증가함에 따라 이러한 수리에 필요한 시간은 점점 더 어려워지고 있습니다.

Ext3의 가장 큰 특징은 ext2를 기반으로 로그 기능을 추가한다는 점이라 ext3 파일 시스템을 흔히 로그 파일 시스템이라고 부르는데, 로그 파일 시스템은 ext3뿐만 아니라 JFS, reiserFS, XFS도 있다. Windows에서 자주 볼 수 있는 NTFS 등도 있습니다.

Ext3의 로깅 기능은 주로 그 아래에 있는 JBD(Journaling Block Device Layer, 줄여서 JBD)라는 중간 장치인 "Journaling Block Device Layer"에 의존합니다. JBD는 파일 시스템 사양의 일부가 아닙니다. ext3 파일 시스템 사양과는 아무런 관련이 없습니다. JBD는 파일 시스템 트랜잭션 처리 기능 구현의 기반입니다. 간단히 말해서, JBD는 모든 블록 장치에 로그인이라는 특별한 목적을 구현하도록 설계되었습니다.

트랜잭션에 관해서는 데이터베이스 개발이나 데이터 운영 및 유지 관리 경험이 있는 학생이라면 확실히 익숙할 것입니다. 트랜잭션의 주요 기능은 운영의 원자성을 보장하는 것이라는 점을 모두가 알고 있는 한 여기서는 개념이나 학문적 정의를 고수하지 않을 것입니다. 이 문장을 어떻게 이해해야 할까요? 예를 들어, 금융 시스템에서 X 위안은 A 계좌에서 B 계좌로 이체되어야 합니다. 이 기업은 X위안이 계좌 A에서 성공적으로 이체된 다음 X위안이 계좌 B에 성공적으로 추가되었는지 확인해야 합니다. 이 두 작업이 동시에 성공하는 경우에만 전송이 성공할 수 있습니다. 두 작업 중 하나라도 실패하면 사업이 종료되어야 합니다. A 계좌에서 X 위안 이체에 성공하고 B 계좌에 쓰는 동안 오류가 발생하면 A 계좌에서 이체된 X 위안을 A 계좌로 반환해야 합니다. 더 극단적인 상황은 다양한 이유로 인해 계정 A의 데이터가 붕괴되는 것입니다. 그런 다음 데이터베이스의 거래 메커니즘은 계정 A의 X 위안이 손실되지 않도록 보장해야 합니다. 이것이 데이터베이스 비즈니스 운영의 원자성입니다. 로그 파일 시스템에서 파일 데이터 작업의 원자성은 JBD에 의해 보장됩니다. Ext3는 JBD API를 "연결"하여 로깅 기능을 구현합니다. JBD 레이어 자체에는 코드가 많지 않지만 매우 복잡한 소프트웨어 부분이므로 여기서는 다루지 않고 기회가 있을 때 사용해 보겠습니다.

로그 파일 시스템은 당연히 로그를 기록해야 하며, 로그에도 저장 공간이 필요합니다. 따라서 로그 파일 시스템은 특히 로그 정보를 저장하기 위해 저장 매체에 특수 영역을 엽니다.

그림을 사용하여 ext3의 기본 레이아웃을 간략하게 설명합니다. CentOS의 저널링 파일 시스템 ext3에 대한 심층 분석