☰

파일 시스템 축소 후 파티션 크기를 너무 작은 값으로 조정

tag-icon • tag-icon partition fsck parted resize2fs e2fsck
파일 시스템 축소 후 파티션 크기를 너무 작은 값으로 조정

ext4다음을 사용하여 파일 시스템을 축소 했습니다 resize2fs.

resize2fs -p /dev/sdn1 3500G

(2.3TB의 경우 FS)

그런 다음 parted를 사용하여 파티션 크기를 조정하고 새 파티션 설정이 끝나면 0.3%의 여백(~10GB)을 남겨 두었습니다.

(parted) resizepart 1 3681027097kb

결국 이것은 너무 빡빡한 것으로 판명되었습니다.

# e2fsck -f /dev/sdn1
e2fsck 1.42.9 (4-Feb-2014)
The filesystem size (according to the superblock) is 917504000 blocks
The physical size of the device is 898688000 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

그런 다음 이번에는 3% 여백으로 파티션 크기를 다시 조정합니다.

(parted) resizepart 1 3681027097kb

그 후 파일 시스템 검사가 통과됩니다.

# e2fsck -f /dev/sdn1
e2fsck 1.42.9 (4-Feb-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdn1: 278040/114688000 files (12.4% non-contiguous), 608536948/917504000 blocks

partprobe /dev/sdn이 두 명령을 resizepart실행 했습니다 .

파일 시스템을 마운트하지 않고(아직 마운트하지도 않은 상태에서) 이 전체 프로세스를 진행했습니다.

파티션 크기를 너무 작은 값으로 조정하는 중간 단계에서 파일 시스템이 손상됩니까?

성공적인 실행 e2fsck만으로도 데이터가 손상되지 않았음을 확인할 수 있습니까?

답변1

파티션 크기를 너무 작은 값으로 조정하여 파일 시스템이 손상되었습니까?

특히 귀하가 fs(c) 킬러를 막을 만큼 친절했기 때문에 귀하의 경우에는 그럴 가능성이 낮지만 이를 완전히 배제할 수는 없습니다.

예를 들어 msdos 파티션 테이블의 확장 파티션 내의 논리 파티션인 경우 손상이 발생합니다. 논리 파티션은 연결된 목록이므로 연결된 목록의 다음 파티션을 가리키는 논리 파티션 사이에 섹터가 있습니다. 이러한 논리 파티션을 축소/크기 조정하면 디스크 중간 어딘가의 일부 섹터(부분)를 덮어쓰게 됩니다.

또한 일부 파티셔너는 항목을 0으로 만드는 것을 좋아할 수도 있습니다. LVM도 마찬가지입니다. 모든 lvcreate에서 생성된 LV의 첫 번째 4K를 0으로 만들고 잘못된 lvresize를 되돌리면 이전에 사용한 것과 동일한 범위가 제공된다는 보장도 없습니다. 운이 좋지 않은 경우 LV가 다른 물리적 위치에 있을 수 있으므로 이전에 만든 크기를 조정해야만 vgcfgrestore이러한 사고를 취소 할 수 있습니다./etc/lvm/{backup,archive}/

SSD에는 다양한 프로그램이 SSD에 승인되지 않은 TRIM 명령을 실행하게 하는 TRIM 유행이 있습니다. LVM은 issue_discards=1다양한 파티셔너가 이 동작을 채택하지 않기를 바라면서 lvm.conf에서 이 작업을 수행합니다 (항상 0으로 설정).

데이터가 손상되지 않았음을 확인할 수 있을 만큼 e2fsck를 성공적으로 실행하고 있습니까?

대부분의 파일 시스템은 자체 메타데이터 외부의 데이터 손상을 감지할 수 없습니다. 이와 같은 묘기를 수행해서는 안 되기 때문에 일반적으로 문제가 되지 않습니다. 백업이 있는 경우 파일 타임스탬프/체크섬을 백업에 있는 내용과 비교할 수 있습니다.

파일 시스템을 마운트하지 않고(아직 마운트하지도 않은 상태에서) 이 전체 프로세스를 진행했습니다.

다음과 같이 읽기 전용으로 마운트할 수 있습니다.

mount -o loop,ro /dev/sdn1 /mnt/somewhere

그런 다음 파일을 봅니다.

loop,ro읽기 전용 루프 장치를 생성하고 마운트하도록 마운트에 지시합니다 . 놀랍게도 일부 파일 시스템( . 포함(전체가 아닌 하나의 장치에만 영향을 미치기 때문에 . 과 같은 다중 장치 파일 시스템도 포함 )) ro에 대해 그 자체로는 이를 보장하지 않습니다 .ext4btrfsloop,ro

관련 정보