ext4 파일 시스템을 축소한 후 resize2fs M마운트해 보니 57%만 사용된 것으로 나타났습니다. 그래서 난 달렸어
$ resize2fs -d 32 -M rootfs-2021-06-28.img
resize2fs 1.44.5 (15-Dec-2018)
fs has 9698 inodes, 1 groups required.
fs requires 115683 data blocks.
With 1 group(s), we have 16352 blocks available.
Added 4 extra group(s), blks_needed 115683, data_blocks 147424, last_start 30686
Last group's overhead is 16416
Need 84997 data blocks in last group
Final size of last group is 101413
Estimated blocks needed: 232485
The filesystem is already 232485 (4k) blocks long. Nothing to do!
115683개의 데이터 블록에 16416개의 오버헤드를 더한 것은 232485의 57%인 것으로 추측되지만 숫자를 232485개의 블록으로 합칠 수는 없습니다. 솔직히 말해서 저는 이 계산 과정을 잘 이해하지 못합니다. 맨페이지는 인정합니다
알려진 오류
resize2fs로 추정한 파일 시스템의 최소 크기는 특히 블록 크기가 1k 및 2k인 파일 시스템의 경우 정확하지 않을 수 있습니다.
하지만 블록 크기는 4k입니다.
resize2fs소수의 블록에 대해 이것이 잘못된 도구 인 경우 파일 시스템을 축소하는 다른 접근 방식을 권장하십시오.
답변1
여기에 설명된 대로 큰 오버헤드 마진이 사용됩니다.
자세한 내용은 연결된 C 코드를 참조하세요.
좀 더 시각적으로 보기 위해 1G 이미지 파일을 사용하여 소규모 테스트를 진행했는데, 점점 더 적은 양의 데이터로 채워졌습니다.파일resize2fs -M그것을 사용하십시오 :
데이터 파일이 900M에서 600M로 줄어들었습니다.이상파티션의 크기.
- 900M: 필요한 예상 블록: 440607(1.68G)
- 800M: 필요한 예상 블록: 382239(1.46G)
- 700M: 필요한 예상 블록: 323871(1.24G)
- 600M: 필요한 예상 블록 수: 298271(1.14G)
500M 이하
- 500M: 필요한 예상 블록 수: 239903(937M)
- 400M: 필요한 예상 블록 수: 181534(709M)
- 300M: 필요한 예상 블록 수: 123166(481M)
- 200M: 필요한 예상 블록 수: 64798(253M)
- 100M: 필요한 예상 블록: 39198(153M)
이와 같은 도구는 gparted뒤에서 사용됩니다. resize2fs파티션을 만들다충전재한 가지 방법은 원하는 크기의 새 이미지 파일을 만들고 거기로 데이터를 이동하는 것입니다. 확실히 일할 공간이 필요합니다.
-f그렇지 않으면 (force) 플래그를 사용 하고 다음을 사용하십시오.
resize2fs -d 32 -f file.img NEW_BLOCK_COUNT
-f Forces resize2fs to proceed with the filesystem resize operation, overriding some safety checks which resize2fs normally enforces.