다음 ext4과 resize2fs같이 파일 시스템을 축소했습니다 .
resize2fs -p /dev/sdn1 3500G
(FS는 2.3TB에 사용됨)
그런 다음 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명령 을 실행했습니다 .
전체 프로세스에서 파일 시스템을 마운트하지 않았습니다 (아직 마운트하지도 않았습니다).
파티션의 크기를 너무 작은 값으로 조정 한 중간 단계에서 fs가 손상되었을 수 있습니까?
성공적인 실행으로 e2fsck데이터가 손상되지 않았는지 확인할 수 있습니까?
파티션의 크기를 너무 작은 값으로 조정하여 fs가 손상 되었습니까?
귀하의 경우에는 그럴 가능성이 거의 없습니다. 특히 fs (c) 살인자를 막을만큼 친절했기 때문에 가능성을 완전히 배제 할 수는 없습니다.
예를 들어, msdos 파티션 테이블의 확장 파티션 내부의 논리 파티션 인 경우 손상이 발생합니다. 논리 파티션은 링크 된 목록이므로 논리 파티션 사이에는 목록의 다음 파티션을 가리키는 데 사용되는 섹터가 있습니다. 이러한 논리 파티션을 축소 / 크기 조정하면 디스크 중간에 섹터 (부분적으로)를 덮어 씁니다.
또한 일부 파티션 프로그램은 제로화를 즐길 수 있습니다. LVM의 경우도 마찬가지입니다. 각 lvcreate에서 생성 된 LV의 첫 번째 4K처럼 0이되고 잘못된 lvresize를 되 돌리면 이전에 사용 된 것과 동일한 범위가 다시 제공된다는 보장이 없습니다. 운이 좋지 않다면 LV가 물리적으로 다른 곳에 위치 할 수 있으므로 lvresize 이전에 생성 된 vgcfgrestore무언가에 의해서만 그러한 사고를 취소 할 수 있습니다 /etc/lvm/{backup,archive}/.
SSD에는 모든 종류의 프로그램이 SSD에 부당한 TRIM 명령을 내리는 TRIM 유행이 있습니다. LVM은 issue_discards=1lvm.conf (항상 0으로 설정) 에서이 작업을 수행합니다 . 여기서 다양한 파티션 프로그램이이 동작을 채택하지 않기를 바랍니다.
e2fsck를 성공적으로 실행하면 데이터가 손상되지 않았는지 확인할 수 있습니까?
Most filesystems are not able to detect data corruption outside of their own metadata. Which is usually not a problem since you're not supposed to pull stunts like these. If you have a backup you could compare file timestamps / checksums with what you have in your backups.
I haven't mounted the filesystem in the whole process (and not mounted it yet even).
You can mount it read-only like so:
mount -o loop,ro /dev/sdn1 /mnt/somewhere
and then check out the files.
The loop,ro tells mount to create a read-only loop device and mount that. Surprisingly, ro by itself does not guarantee readonlyness for some filesystems including ext4. (And for multiple-device filesystems like btrfs, the loop,ro doesn't either because it affects only one device, not all of them).
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다