집 파티션의 크기를 줄이려고 합니다. 나는 팔로우한다아치위키이에 대한 기사입니다. 이를 바탕으로 먼저 파일 시스템 크기 조정을 사용한 resize2fs다음 물리적 장치 크기 조정을 사용했습니다 parted. 매개변수 에서 resize2fs예상 크기를 다음과 같이 지정합니다.XG크기를 조정한 후 새 크기가 다음과 같이 보고됩니다.Y(4k 블록). 이 정보를 바탕으로 내 파티션 크기는 다음과 같다고 계산했습니다.(Y * 4) 키Bparted를 사용하여 물리적 파티션의 크기를 조정할 때 이 크기를 사용했습니다. 하지만 현실은 이렇다(Y * 4)KB. 따라서 이제 파일 시스템의 총 블록 수가 물리적 장치의 총 블록 수보다 높습니다.
맨 페이지 에는 resize2fs크기를 지정하지 않으면 장치의 전체 공간을 차지한다고 명시되어 있습니다. 그래서 이 문제를 해결하기 위해 resize2fs다시 실행하여 파일 시스템 크기를 실제 크기와 일치시켰습니다. 하지만 다음과 같은 오류가 발생합니다.
resize2fs 1.45.6 (20-Mar-2020)
Resizing the filesystem on /dev/sda3 to 159907584 (4k) blocks.
resize2fs: Can't read a block bitmap while trying to resize /dev/sda3
Please run 'e2fsck -fy /dev/sda3' to fix the filesystem
after the aborted resize operation.
하지만 실행하면 e2fsck불일치가 보고되고 중단을 권장합니다. 그래서 이제 나는 루프에 갇혔습니다.
e2fsck 1.45.6 (20-Mar-2020)
The filesystem size (according to the superblock) is 186122240 blocks
The physical size of the device is 159907584 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>?
회복할 수 있는 방법이 있나요? 백업을 만들 수 있도록 파티션을 마운트하고 액세스하는 것이 안전합니까?
감사해요!
답변1
작성한 내용에 따르면 실수로 포함된 파일 시스템보다 파티션을 더 작게 축소했습니다. 그 자체로는 데이터가 손실되지 않지만 그 이후에 수행할 수 있는 거의 모든 작업이 손실될 수 있습니다. 여기에는 확실히 resize2fs, e2fsck및 가 포함됩니다 mount. 실행한 두 명령 모두 문제를 감지하고 중단했기 때문에 매우 운이 좋았던 것 같습니다.
가장 큰 질문은 파티션을 축소하여 생성된 추가 공간으로 어떤 조치를 취했습니까? 이렇게 하면 추가 파티션을 만들면그리고 포맷해라, 귀하의 데이터는 복구할 수 없을 정도로 손상될 수 있습니다. 그렇지 않다면 아마도 괜찮을 것입니다.
parted현재 문제를 해결하려면 파티션을 원래 크기로 복원하는 것과 같은 도구를 사용해야 합니다 . 여유 공간에 아무 작업도 수행하지 않은 경우 데이터는 남겨둔 위치에 그대로 있어야 합니다. 이렇게 하면 당면한 문제가 해결되며 이를 사용하여 e2fsck다시 확인할 수 있습니다. 중단하다처음과 비슷한 경고가 표시되는 경우.
문제의 근본 원인은 파일 시스템을 올바르게 축소하지 않았기 때문입니다.resize2fs 앞으로축소 분할을 사용합니다 parted. 이는 파티션에서 제거하려는 공간 밖으로 파일 데이터를 이동하는 데 필요합니다.
나는 알아차렸다위키피디아resize2fs귀하의 견적은 치수를 지정해야 함을 올바르게 나타냅니다.
...단위에 매우 주의하고 입력한 숫자를 이해하는 데 시간을 투자하세요. ext2/3/4의 4k 블록은 4096바이트를 의미합니다. 다른 곳에서는 "블록"이라는 용어가 완전히 다른 의미를 가질 수도 있습니다. 많은 파티셔닝 프로그램 parted에서는 KB, MB...와 KiB, MiB도 구분합니다. 원하는 단위가 무엇인지 확인하십시오.
- KB = 1,000MB = 1,000,000
- KiB = 1,024MiB = 1,048,576