☰

LVM 볼륨을 0으로 만드는 문제

tag-icon • tag-icon linux lvm dd
LVM 볼륨을 0으로 만드는 문제

내 시스템에는 eMMC 장치에 두 개의 LVM 볼륨이 있고 볼륨 중 하나를 0으로 채워 "삭제"하려고 합니다. LVM을 처음 사용하는 것이므로 성공하지 못한 채 시도한 내용을 보여 드리겠습니다.

먼저, 저는 항상 pvdisplay -m볼륨이 어떻게 설정되어 있는지 살펴봅니다.

# pvdisplay -m
  --- Physical volume ---
  PV Name               /dev/mmcblk0p2
  VG Name               vg0
  PV Size               3.42 GiB / not usable 3.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              876
  Free PE               776
  Allocated PE          100
  PV UUID               i2Abz2-4o2h-9hq4-Gk3h-b5SD-0r9M-7oDfh3

  --- Physical Segments ---
  Physical extent 0 to 49:
    Logical volume      /dev/vg0/volume_a
    Logical extents     0 to 49
  Physical extent 50 to 99:
    Logical volume      /dev/vg0/volume_b
    Logical extents     0 to 49
  Physical extent 100 to 875:
    FREE

이건 간단해 보이는데

  • VG가 있고,vg0
  • vg0PV 1개로 구성되어 있으며,/dev/mmcblk0p2
  • PV는 3.42GiB이며 876개의 4MiB PE로 나뉩니다.
  • PE [0, 49]는 첫 번째 LV를 저장하고,volume_a
  • PE [50, 99]는 두 번째 LV를 저장하고 있으며,volume_b

volume_b이를 염두에 두고 저는 이를 제로화 하려고 노력했습니다 dd.

# dd if=/dev/zero of=/dev/vg0/volume_b bs=1M count=200
201+0 records in
200+0 records out
209715200 bytes (210 MB, 200 MiB) copied, 17.2374 s, 12.2 MB/s

출력에 기초하여 PE [50, 99] (200M-400M) 가 0으로 채워져야 한다고 pvdisplay -m가정합니다 . /dev/mmcblk0p2그러나 이것이 내가 보는 것입니다:

# hexdump /dev/mmcblk0p2 -s 200m
c800000 0000 0000 0000 0000 0000 0000 0000 0000
*
c900400 c800 0000 2000 0003 2800 0000 f0ad 0002
c900410 c7f5 0000 0001 0000 0000 0000 0000 0000

0이 몇 개 있지만 1MiB에만 해당됩니다. 그런 다음 임의의 숫자로 채우고 다시 확인했습니다.

# dd if=/dev/urandom of=/dev/vg0/volume_b bs=1M count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB, 200 MiB) copied, 99.9135 s, 2.1 MB/s
# hexdump /dev/mmcblk0p2 -s 200m
c800000 0000 0000 0000 0000 0000 0000 0000 0000
*
c900400 c800 0000 2000 0003 2800 0000 f0ad 0002
c900410 c7f5 0000 0001 0000 0000 0000 0000 0000

이전과 똑같아서 내 dd통화가 내 생각대로 진행되지 않는 것 같습니다. 내 가정은 LV가 /dev/vg0/volume_b"가상" 블록 장치이고 dd여기에 쓸 때 LVM이 이를 실제 블록 쓰기를 위해 해당 PE에 매핑한다는 것입니다. 불행히도 이것은 내가 보는 것과 일치하지 않습니다.

[편집 1] 확인해 보니 hexdump놀랍지 /dev/vg0/volume_b도 않게 무작위 쓰레기로 가득 차 있습니다. 방금 hexdump전체 프로세스를 깨닫고 데이터가 저장된 위치를 찾는 데 /dev/mmcblk0p2사용했습니다 . grep지금은 원활하게 진행되고 있으니 업데이트되면 업데이트하겠습니다.

[편집 2] 검색 결과가 없습니다.

답변1

추가 테스트 결과 LVM 및 Linux 커널과의 관계에 문제가 있는 것으로 나타났습니다. 디스크 캐싱과 관련된 것으로 추측되지만 100% 확실하지는 않습니다. 이것이 내가 찾은 것입니다:

먼저 LVM 볼륨에 정크 데이터를 씁니다.

# dd if=/dev/urandom of=/dev/vg0/volume_b bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.600447 s, 1.7 MB/s

그런 다음 LVM 볼륨을 다시 읽었습니다. 다음은 작성된 쓰레기의 일부입니다.

# hexdump /dev/vg0/volume_b -n 0x20
0000000 2358 898b a13b 8d94 39a1 bff6 8b38 79ec
0000010 9155 1202 ce46 938f 49dc 7687 f804 bf13
0000020

그러나 블록 장치 자체를 확인하면 아무것도 변경되지 않습니다.

# hexdump /dev/mmcblk0p2 -s 200M
c800000 0000 0000 0000 0000 0000 0000 0000 0000
*
c900000 2dee 8ea4 2116 1981 252f d113 afc1 3182
c900010 e6fc 7d1b d173 3cab 4399 8715 bcdf 2272

1MiB의 0이 있고 그 뒤에 방금 LVM 볼륨에 기록된 내용과 일치하지 않는 일부 쓰레기가 있습니다. 하지만 재미삼아 시스템을 다시 시작하고 다시 확인해 보았습니다.

# hexdump /dev/mmcblk0p2 -s 200M
c800000 0000 0000 0000 0000 0000 0000 0000 0000
*
c900000 2358 898b a13b 8d94 39a1 bff6 8b38 79ec
c900010 9155 1202 ce46 938f 49dc 7687 f804 bf13

데이터가 있습니다! 여전히 1MiB의 0 부분(아마도 헤더?)이 있지만 기록된 데이터 /dev/vg0/volume_b는 /dev/mmcblk0p2.

이건 정말 설명할 수가 없어요. 내 생각에는 LVM과 커널 드라이버 사이의 링크, 더 구체적으로 커널이 디스크 캐싱을 처리하는 방법에 문제가 있을 수 있습니다. LV를 통해 현재 캐시된 영역에 물리적 디스크를 쓰는 경우 캐시가 업데이트되지 않거나 더티로 표시되지 않을 수 있습니까?

임베디드 시스템이라 전원을 껐다가 다시 켜서 시스템 재부팅을 해보았습니다. 동작은 정확히 동일합니다. 정전이 발생하기 전에는 hexdump오래된 데이터가 물리적 장치에 나타나며 재부팅 후 새로 작성된 데이터로 업데이트됩니다. 이는 쓰기가 완료된 후 디스크로 플러시되며 Linux 전원 끄기 프로세스의 일부가 아님을 나타냅니다.

근본 원인이 무엇인지 아직 확실하지 않기 때문에 지금은 이 질문을 열어 두겠습니다. 그러나 적어도 문제가 실제로 문제가 아니라는 것은 알고 있습니다.

[편집] 실제로 캐시가 범인인 것 같습니다. echo 3 > /proc/sys/vm/drop_caches쓰기 후에 실행하면 다시 읽기 시 즉시 업데이트됩니다. 웰프.

관련 정보