ext4 볼륨의 파일이 왜 조각난 것입니까?


19

ext4결함이없고 불량 섹터가없는 (자기) 하드 드라이브에 900GB 파티션이 있습니다. 빈 lost+found디렉토리를 제외하고 파티션이 완전히 비어 있습니다. 예약 된 파일 시스템 블록 수를 1 %로 설정 한 것을 제외하고는 기본 매개 변수를 사용하여 파티션을 포맷했습니다.

~ 900MB 파일 xubuntu-15.04-desktop-amd64.iso을을 사용하여 파티션의 마운트 지점 디렉토리로 다운로드했습니다 wget. 다운로드가 완료되면 파일이 네 개의 조각으로 분할 된 것을 발견했습니다.

filefrag -v /media/emma/red/xubuntu-15.04-desktop-amd64.iso
Filesystem type is: ef53
File size of /media/emma/red/xubuntu-15.04-desktop-amd64.iso is 1009778688 (246528 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  190463:     198656..    229375:  30720:            
   6:   190464..  223231:     231424..    264191:  32768:     229376:
   7:   223232..  246527:     264192..    287487:  23296:             eof
/media/emma/red/xubuntu-15.04-desktop-amd64.iso: 4 extents found

이것이 wget어떻게 든 관련 이 있다고 생각 하여 파티션에서 ISO 파일을 제거하고 다시 비운 다음 ~ 700MB 파일 v1.mp4을 파티션을 사용하여 파티션에 복사했습니다 cp. 이 파일도 조각화되었습니다. 세 개의 조각으로 나뉘 었습니다.

filefrag -v /media/emma/red/v1.mp4
Filesystem type is: ef53
File size of /media/emma/red/v1.mp4 is 737904458 (180153 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  180152:     198656..    219064:  20409:             eof
/media/emma/red/v1.mp4: 3 extents found

왜 이런 일이 발생합니까? 그리고 그것을 막을 수있는 방법이 있습니까? 나는 ext4조각화에 저항해야 한다고 생각했다 . 대신 나머지 볼륨을 모두 사용하지 않으면 독방 파일이 즉시 조각화됩니다. 이 둘보다 더 나쁜 것 같다 FAT32NTFS.


4
어떤 상황에서 이것이 문제가 될 수 있는지 상상하려고 노력하고 있으며 비어 있습니다.
Greg Hewgill

4
@GregHewgill : 비정상이라고 생각했기 때문에 문제가되었습니다. 이제는 정상이라는 것을 알고 있습니다. 그것은 중요하지 않습니다.
EmmaV

답변:


17

900mb 파일의 3 개 또는 4 개 조각 매우 좋습니다. 해당 크기의 파일에 100 개 이상의 조각이 있으면 조각화가 문제가됩니다. fat 또는 ntfs가 그러한 파일을 수백 조각으로 분할하는 것은 드문 일이 아닙니다.

블록 그룹의 최대 크기는 128MB이므로 128MB마다 연속적인 공간이 할당 비트 맵 및 inode 테이블에 대한 몇 개의 블록으로 나뉘어져 있기 때문에 일반적으로 적어도 오래된 ext4 파일 시스템에서는 그보다 더 잘 보이지 않습니다. 다음 블록 그룹. flex_bg 라는 최신 ext4 기능을 사용하면 이러한 테이블의 많은 (일반적으로 16 개) 블록 그룹을 함께 묶을 수 있으므로 할당 가능한 블록이 더 오래 실행되지만 분포와 포맷에 사용 된 e2fsprogs 버전에 따라이 옵션이 사용되지 않았습니다.

tune2fs -l파일 시스템 포맷시 활성화 된 기능을 확인하는 데 사용할 수 있습니다 .


매우 흥미로운. 모든 inode 테이블 등이 볼륨의 시작 부분에 있다고 가정했습니다.
EmmaV

1
@EmmaV는 그들이 참조하는 데이터에 상대적으로 가까운 디스크 전체에 그것들을 분배함으로써, 더 짧은 탐색과 더 빠른 디스크 액세스를 초래합니다 :)
hobbs

10

나는 정말로 대답 할 수는 없지만 이것이 도움이 될 것이라고 생각합니다.

각 프래그먼트의 크기가 최대 32768 블록 (2의 거듭 제곱 인 경우, 무언가 진행중인 플래그를 제기하고 찾아야 할 힌트를 제공함)을 확인하십시오.

또한 익스텐트 사이의 물리적 오프셋은 서로 매우 가깝습니다.

보낸 사람 : Ext4 디스크 레이아웃

ext4 파일 시스템은 일련의 블록 그룹으로 나뉩니다. 조각화로 인한 성능 문제를 줄이기 위해 블록 할당자는 각 파일의 블록을 동일한 그룹 내에 유지하기 위해 매우 노력하여 검색 시간을 줄입니다. 블록 그룹의 크기는에 지정되어 sb.s_blocks_per_group blocks있지만 8 *으로 계산할 수도 있습니다 block_size_in_bytes. 기본 블록 크기가 4KiB 인 경우 각 그룹은 길이가 128MiB 인 32,768 개의 블록을 포함합니다.

그리고 더 아래로 :

ext4가 조각화를 막기 위해 사용하는 첫 번째 도구는 멀티 블록 할당 자입니다. 파일이 처음 생성 될 때, 블록 할당자는 추론 적으로 8KiB의 디스크 공간을 파일에 할당합니다 ...] ext4가 사용하는 두 번째 관련 트릭은 지연된 할당입니다. 이 구성에서 파일에 파일 쓰기를 흡수하기 위해 더 많은 블록이 필요한 경우 파일 시스템은 모든 더티 버퍼가 디스크에 기록 될 때까지 디스크의 정확한 배치를 결정합니다. 절대적으로 필요할 때까지 (커밋 시간이 초과되거나 sync ()가 호출되거나 커널에 메모리가 부족할 때까지) 특정 배치에 커밋하지 않으면 파일 시스템이 더 나은 위치 결정을 내릴 수 있기를 바랍니다.

따라서 할당자는 블록 그룹 (32K 블록) 내의 데이터 위치 에만 신경을 쓰지만 블록 그룹이 서로 인접하지는 않습니다.


첫 번째 인용문은 내 질문에 대한 답변입니다.
EmmaV

1
익스텐트 는 익스텐트 디스크립터가 커버 할 수있는 최대 길이이므로 최대 32k 블록을 갖습니다. 익스텐트는 프래그먼트가 아닙니다. 여러 익스텐트의 물리적 블록이 바로 이전 익스텐트의 블록을 따르므로 조각을 구성하지 마십시오 (6 개의 익스텐트 대 3 개의 프래그먼트).
psusi
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.