당신이 읽으면서여기ext4 파일 시스템에는 블록을 범위로 그룹화하는 범위 기능이 있습니다. 각각 최대 128MiB의 연속 공간을 가질 수 있습니다. 에는 e4defrag
다음과 유사한 줄이 있습니다.
[325842/327069]/file: 100% extents: 100 -> 10 [ OK ]
파일 크기는 약 150MiB입니다. 따라서 위키 페이지에 따르면 10개가 아닌 2개의 범위가 있어야 합니다.
- 범위가 128MiB가 아닌 15MiB인 이유를 아는 사람이 있습니까?
- 정확한 범위 크기를 확인할 수 있는 도구가 있나요?
- 128MiB가 되도록 크기를 어떻게 변경합니까?
답변1
귀하의 질문은 잘못된 전제에 근거한 것 같습니다.
기본적으로...당신의 범위예크기는 128MB이지만 e4defrag는 파일을 가져오고 해당 데이터를 복사한 후 복사본에 10개가 아닌 5개의 범위가 있음을 발견하여 이를 "성공"이라고 부르고 inode를 복사된 데이터를 가리키며 원본 데이터를 해제합니다. 이런 일이 발생하면 "10 -> 5"가 인쇄됩니다.
(이제 데이터를 복사하는 것도 가능합니다.더이 경우 복사본을 제거하고 그대로 두고 "10 -> 10"을 인쇄합니다. )
디스크가 가득 차면 e4defrag가 파일 크기를 기준으로 계산된 "최소" 범위 수로 파일을 축소할 가능성이 줄어듭니다.
그러나 e4defrag가 디스크 조각 모음을 완벽하게 수행할 것이라고 기대하지 마십시오. 파일당 한 번(여러 범위가 있는 파일당, 즉 이미 하나의 범위만 있는 경우(또는 가능한 가장 작은 것으로 추측)) 조금 느리게 시도합니다. 건너뜁니다) 그리고 이 시도가 어떤 종류의 개선으로 이어지지 않으면 그냥 그대로 두고 개선이 있더라도 가능한 최소 범위 수가 보장되지는 않습니다. 특히 마지막 실행 이후 더 많은 공간이 확보된 경우 첫 번째 실행 후 e4defrag를 다시 실행하면 약간의 개선을 얻을 수 있지만 첫 번째 실행 후 후속 실행에서는 수익 감소가 빠르게 발생할 수 있습니다.
답변2
나는 그것이 어떻게 작동하는지 알고 있다고 생각합니다.
~458G의 파티션이 거의 비어 있었기 때문에 다른 디스크를 내 컴퓨터에 연결했습니다. 다음을 통해 사용 가능한 공간을 확인했습니다 e2freefrag
.
HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range : Free extents Free Blocks Percent
64M... 128M- : 6 146233 0.12%
128M... 256M- : 5 322555 0.27%
256M... 512M- : 3 263897 0.22%
512M... 1024M- : 6 1159100 0.98%
1G... 2G- : 228 116312183 98.40%
그것은 단지 연속된 자유 블록일 뿐입니다. 파티션이 거의 비어 있기 때문에 여유 공간이 많고 1-2G 블록이 228개 있습니다.
파티션에 대용량 2.5G 파일을 배치했는데 위 표에서 일부 변경 사항이 발생했습니다.
HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range : Free extents Free Blocks Percent
2M... 4M- : 5 5114 0.00%
64M... 128M- : 7 170777 0.14%
128M... 256M- : 1 64511 0.05%
256M... 512M- : 4 361579 0.31%
512M... 1024M- : 5 930749 0.79%
1G... 2G- : 227 116025495 98.16%
이는 할당된 블록 범위에 대해 아무 것도 알려주지 않지만 몇 가지 아이디어를 제공합니다. 에 있는 파일을 보면 e4defrag
다음과 같은 내용이 있습니다.
# e4defrag -cv file
<File>
[ext 1]: start 34816: logical 0: len 32768
[ext 2]: start 67584: logical 32768: len 30720
[ext 3]: start 100352: logical 63488: len 32768
[ext 4]: start 133120: logical 96256: len 30720
[ext 5]: start 165888: logical 126976: len 32768
[ext 6]: start 198656: logical 159744: len 30720
[ext 7]: start 231424: logical 190464: len 32768
[ext 8]: start 264192: logical 223232: len 30720
[ext 9]: start 296960: logical 253952: len 32768
[ext 10]: start 329728: logical 286720: len 32768
[ext 11]: start 362496: logical 319488: len 32768
[ext 12]: start 395264: logical 352256: len 32768
[ext 13]: start 428032: logical 385024: len 32768
[ext 14]: start 460800: logical 417792: len 32768
[ext 15]: start 493568: logical 450560: len 30720
[ext 16]: start 557056: logical 481280: len 32768
[ext 17]: start 589824: logical 514048: len 32768
[ext 18]: start 622592: logical 546816: len 32768
[ext 19]: start 655360: logical 579584: len 32768
[ext 20]: start 688128: logical 612352: len 32768
[ext 21]: start 720896: logical 645120: len 622
이 숫자 32768
는 블록(4K)을 나타내며 128MiB와 같습니다. 그 중 일부는 블록 수가 더 적습니다. 이유는 모르겠습니다. 파일 시스템이 비어 있기 때문에 모든 익스텐트에는 32768개의 블록이 있어야 한다고 생각합니다.
어쨌든, 메인 파티션의 여유 공간을 확인했는데 다음과 같은 내용이 있었습니다.
HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range : Free extents Free Blocks Percent
4K... 8K- : 3955 3955 0.06%
8K... 16K- : 3495 8194 0.13%
16K... 32K- : 2601 13165 0.20%
32K... 64K- : 2622 28991 0.45%
64K... 128K- : 2565 58267 0.90%
128K... 256K- : 1576 71371 1.11%
256K... 512K- : 1331 118346 1.83%
512K... 1024K- : 1058 190532 2.95%
1M... 2M- : 1202 444210 6.89%
2M... 4M- : 1211 884489 13.71%
4M... 8M- : 1249 1803998 27.97%
8M... 16M- : 622 1643226 25.48%
16M... 32M- : 198 1024999 15.89%
32M... 64M- : 16 163082 2.53%
보시다시피, 128M(또는 그 이상)의 공간을 제공할 수 있는 무료 연속 블록이 없습니다. 이것이 바로 위키에 "최대" 128M의 확장을 가질 수 있다고 쓴 이유입니다.
관련 파일에 왜 10개의 범위가 있는지 잘 모르겠습니다. 최소 32M의 블록이 여전히 16개 있기 때문입니다.