☰

ext4 파일 시스템의 로그에는 어떤 유형의 데이터가 저장됩니까?

tag-icon • tag-icon filesystems security hard-disk
ext4 파일 시스템의 로그에는 어떤 유형의 데이터가 저장됩니까?

파일 ext4시스템에는 이라는 파일 시스템이 있습니다 has_journal. dumpe2fs출력에서 ​​다음과 같은 내용을 볼 수 있습니다.

# dumpe2fs /dev/sda2 | grep -i journal
Journal inode:            8
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             32M
Journal length:           8192
Journal sequence:         0x00000662
Journal start:            1

따라서 로그 크기는 32M이고 파일 시스템의 처음부터 시작됩니다. 로그의 크기는 파티션의 크기에 따라 다르다는 것을 알고 있습니다. 지금은 한도가 얼마였는지 기억나지 않지만 별로 가치가 없었습니다. 그러면 로그에는 어떤 종류의 데이터가 저장되나요?

디스크에서 파일을 안전하게 삭제하려면(을 통해 shred) 삭제된 파일에 대한 일부 정보를 저장할 수 있는 파일 시스템의 로그를 고려해야 한다는 내용을 읽은 적이 있습니다. 일기 내용을 확인할 수 있는 방법이 있나요? 이 정보를 표시할 수 있는 도구가 있나요?

답변1

로그의 정확한 내용은 ext4 파일 시스템을 구성한 방법에 따라 다릅니다. 이것ext4 공식 문서설명하다:

3가지 데이터 모드가 있습니다:

  • Writeback 모드 data=writeback 모드에서 ext4는 데이터를 전혀 기록하지 않습니다. 이 모드는 XFS, JFS 및 ReiserFS의 기본 모드인 메타데이터 로깅과 유사한 로깅 수준을 제공합니다. 충돌 + 복구로 인해 충돌 직전에 작성된 파일의 데이터가 잘못될 수 있습니다. 이 모드는 일반적으로 최고의 ext4 성능을 제공합니다.

  • Ordered 모드 data=ordered 모드에서 ext4는 형식적으로 메타데이터만 기록하지만, 데이터 블록을 사용하여 데이터 변경과 관련된 메타데이터 정보를 트랜잭션이라는 단일 단위로 논리적으로 그룹화합니다. 새로운 메타데이터를 디스크에 기록해야 하는 경우 관련 데이터 블록이 먼저 기록됩니다. 일반적으로 이 모드는 쓰기 저장보다 약간 느리게 수행되지만 로그 모드보다 훨씬 빠릅니다.

  • 저널 모드 데이터=저널 모드는 완전한 데이터 및 메타데이터 로깅을 제공합니다. 모든 새 데이터는 먼저 로그에 기록된 다음 최종 위치에 기록됩니다. 충돌이 발생하면 로그를 재생하여 데이터와 메타데이터를 일관된 상태로 만들 수 있습니다. 이 모드는 데이터를 디스크에서 동시에 읽고 써야 하는 경우를 제외하고 가장 느립니다. 이 경우 다른 모든 모드보다 성능이 뛰어납니다. 이 모드를 활성화하면 지연 할당 및 O_DIRECT 지원이 비활성화됩니다.

따라서 메타데이터(예: 파일 이름)와 실제 데이터(예: 파일 내용)가 모두 로그 파일에 존재할 수 있습니다.

트랜잭션 데이터가 실제로 로그에 저장되는 형식에 대한 세부 정보에 관심이 있는 경우 해당 헤더 파일을 참조해야 합니다.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/jbd2.h

이러한 구조가 디스크에 어떻게 배치되는지 설명하는 위키 페이지도 있습니다.

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout

또는 sleuthkit와 같은 도구가 있는 데비안이라는 패키지가 있습니다 . 이 도구는 파일 시스템에 대한 모든 로그 항목을 나열할 수 있습니다 . 예를 들면 다음과 같습니다.jlsjcatjlsext4

# jls grafi.img

JBlk    Description
0:      Superblock (seq: 0)
sb version: 4
sb version: 4
sb feature_compat flags 0x00000000
sb feature_incompat flags 0x00000000
sb feature_ro_incompat flags 0x00000000
1:      Allocated Descriptor Block (seq: 2)
2:      Allocated FS Block 161
3:      Allocated Commit Block (seq: 2, sec: 1448889478.49360128)
4:      Allocated Descriptor Block (seq: 3)
5:      Allocated FS Block 161
6:      Allocated Commit Block (seq: 3, sec: 1448889494.3355841024)
7:      Allocated Descriptor Block (seq: 4)
8:      Allocated FS Block 145
9:      Allocated FS Block 1
10:     Allocated FS Block 161
11:     Allocated FS Block 129
12:     Allocated FS Block 8359
13:     Allocated FS Block 8353
14:     Allocated FS Block 0
15:     Allocated FS Block 130
16:     Allocated Commit Block (seq: 4, sec: 1448889528.3540304896)
...

물론, 저널의 크기에 따라 더 많은 항목이 있을 것입니다. 이 경우 대략 16382개가 있는데, 대부분이 비어있습니다. 일부 파일 복원과 같은 일부 작업을 로그에서 수행하려면 jcat다음 명령을 사용하여 inode 블록을 추출해야 합니다.

jcat grafi.img 8 10 > blok-161

단일 i-노드를 확인합니다. 블록의 4096크기는 바이트 단위이며 16i-노드를 포함하며 각 i- 256노드는 길이가 바이트입니다. 어쨌든 이 방법을 사용하면 범위의 첫 번째 블록, 해당 범위의 블록 수, 특정 파일을 설명하는 데 사용되는 범위 수, 크기 및 기타 유사한 정보를 얻을 수 있습니다. 로그에서 얻은 i-node 항목을 기반으로 디스크에서 파일을 복원할 수 있습니다.

debugfs그것은 또한 포장에 포함되어 있습니다 e2fsprogs. logdump와 비슷한 도구가 있습니다 jls.

답변2

Wikipedia의 저널링 파일 시스템 정의를 참조하고 답변을 얻을 수 있기를 바랍니다.

저널링 파일 시스템은 "로그"(보통 순환 로그)라는 데이터 구조에 이러한 변경 의도를 기록하여 파일 시스템의 주요 부분에 아직 커밋되지 않은 변경 사항을 추적하는 파일 시스템입니다. 시스템 충돌이나 정전이 발생하는 경우 이러한 파일 시스템을 더 빨리 온라인으로 되돌릴 수 있으며 손상될 가능성이 적습니다.

인용하다:

https://en.wikipedia.org/wiki/Ext4#Features 그리고 https://en.wikipedia.org/wiki/Journaling_file_system#Logical_journals

자세한 내용은.

관련 정보