☰

LUKS-LVM 파티션 크기 조정 문제

tag-icon • tag-icon filesystems lvm luks forensics
LUKS-LVM 파티션 크기 조정 문제

LUKS lvm 파티션의 크기를 조정(축소)하려고 하는 걱정스러운 모험을 겪었습니다. 시스템을 더 작은 크기의 새 드라이브에 쉽게 복사할 수 있도록 파티션을 축소하고 싶습니다. 시작하기 전에 여유 공간을 확보하기 위해 기존 디스크에서 일부 파일을 삭제했습니다. 그 후 USB 라이브 우분투에서 부팅하고 KDE 파티션 관리자를 사용하여 먼저 LUKS 파티션의 잠금을 해제했습니다. 그런 다음 LVM 루트 파티션을 사용 가능하게 만들고 KDE 파티션 관리자의 크기 조정 옵션을 사용하여 축소했습니다. 불행히도 이로 인해 여기에 설명된 것과 동일한 문제가 발생합니다. "파티션 크기를 조정한 후 슈퍼블록 또는 파티션 테이블이 손상되었을 수 있습니다!"

내 문제는 답변 중 하나를 오해하는 것에서 시작됩니다. 그래서 내가 한 일은 다음 명령을 실행하는 것이었습니다.

e2fsck -f /dev/the_unlocked_lvm_root

다음 옵션 중에서 선택하십시오.

e2fsck 1.45.5 (07-Jan-2020)
The filesystem size (according to the superblock) is 239771648 blocks
The physical size of the device is 125080576 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? no
Pass 1: Checking inodes, blocks, and sizes
Error reading block 126877728 (Input/output error) while getting next inode from scan.  Ignore error<y>? yes
Force rewrite<y>? yes

때때로 나는 내가 해야 할 일을 하고 있지 않다는 것을 깨달을 때까지 "예"를 누릅니다. 이제 컴퓨터를 다시 시작하거나 다른 작업을 수행하지 않았습니다. 내 질문은 기본적으로 내가 얼마나 많은 피해를 입혔는지, 문제가 복구 가능한지, 아니면 모든 데이터가 손실되었는지입니다. e2fsck 명령을 중지하면 "파일 시스템이 수정되었습니다"라는 메시지가 표시되므로 매우 걱정됩니다.

어떤 피드백이라도 대단히 감사하겠습니다!

답변1

방금 비슷한 문제가 있었는데 해결할 수있었습니다. KDE Partition Manager를 사용하는 대신 lvresize다음 명령을 사용하여 논리 볼륨의 크기를 조정했습니다.

이 명령을 실행하지 마십시오:lvresize --verbose -L -40G /dev/mapper/vgubuntu-root

내 질문은 기본적으로 내가 얼마나 많은 피해를 입혔는지, 문제가 복구 가능한지, 아니면 모든 데이터가 손실되었는지입니다.

무슨 일이에요?

다음 설명은내 가설그리고 일부 오류가 있을 수 있으니, 오해를 해소하기 위해 자유롭게 수정/댓글 부탁드립니다.

  1. 첫째, 논리 볼륨은 파티션 테이블이나 파일 시스템이 아닌 하드 드라이브와 유사한 볼륨입니다.

  2. 파일 시스템은 논리 볼륨 내부에 상주하므로 내가 이해하는 한 논리 볼륨에는 파티션 테이블이 없습니다. (파티션이 아닌 전체 디스크에 파일 시스템을 생성하는 것이 가능하지만 일반적이지 않습니다.)

  3. 파일 시스템을 축소하지 않고 볼륨을 축소하는 것은 하드 드라이브의 섹터를 자르는 것과 같습니다. 파티션 테이블이 없기 때문에 KDE 파티션 관리자는 볼륨이 비어 있는 것으로 간주하여 사용자가 자유롭게 편집할 수 있도록 합니다.

  4. 이제 볼륨은 줄어들었지만 파일 시스템에는 여전히 볼륨 범위 외부에 있는 블록이 있으므로 e2fsck읽을 수 없으며 block 126877728볼륨 범위 외부에 있습니다.

  5. e2fsck원 하지만 rewrite블록에 전혀 접근할 수 없기 때문에 그럴 수 없습니다.

  6. 볼륨 크기와 파일 시스템에 대한 정보는 파티션의 시작 부분을 덮고 있는 물리적인 하드 드라이브에 저장되기 때문에,데이터가 거의 손실되지 않습니다., 적어도 HDD에서는 (아마도 SSD에서). 이번에도 e2fsck블록을 다시 쓸 수 없으며 비트와 바이트는 실제 하드 드라이브 어딘가에 거의 그대로 남아 있습니다.

  7. 따라서 파일 시스템을 건드리지 않고 단순히 논리 볼륨 크기를 늘려 축소를 취소하면 문제가 해결됩니다.

긴 이야기 짧게

볼륨을 원래 크기로 복원하면 데이터 손실 없이 문제가 해결됩니다.

lvresize --verbose -L +SIZE /dev/mapper/vgubuntu-root
    # SIZE you shrunk the volume
    # `lvresize` <volume> => resize a logical volume
    #   --verbose  => Give more info.
    #   --resizefs => Resize filesystem AND LV with fsadm(8).
    #   -L         => Specifies the new size of the LV, 
    #                 +/- add/subtracts to/from current size, e.g. g|G is GiB.

e2fsck -f /dev/mapper/vgubuntu-root
    # `e2fsck` <fs-path> => Check a Linux ext2/ext3/ext4 file system
    #   -f => Force checking even if the file system seems clean.

    # Output should look like this:
    #   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

원래 크기를 모른다면, 이후에 볼륨 크기(상위 파티션의 경계 내에서)를 늘릴 수 있으며, e2fsck이후 오류 보고서에 더 적은 수의 블록이 포함되어야 합니다.

lvresize --verbose -L +1G /dev/mapper/vgubuntu-root
e2fsck -f /dev/mapper/vgubuntu-root
    # Block bitmap differences:  +121110528 +(121110532--121110533) +(121110537--121111049) +(121112586--121113097)

lvresize --verbose -L +1G /dev/mapper/vgubuntu-root
e2fsck -f /dev/mapper/vgubuntu-root
    # Block bitmap differences:  +(121110537--121111049) +(121112586--121113097)

lvresize --verbose -L +1G /dev/mapper/vgubuntu-root
e2fsck -f /dev/mapper/vgubuntu-root
    # Pass 5: Checking group summary information

논리 볼륨 및 파일 시스템을 축소하는 방법

lvresize옵션 포함 --resisefs(파일 시스템의 크기가 조정됩니다.- 캡틴 오비어스):

# Shrink logical root volume AND filesystem
lvresize --verbose --resizefs -L -SIZE /dev/mapper/vgubuntu-root

관련 정보