☰

주어진 파일의 LVM 범위 번호 결정

tag-icon • tag-icon linux filesystems performance lvm
주어진 파일의 LVM 범위 번호 결정

나는 현재 업무와 관련되지 않은 숙제를 하고 있습니다. 내 논리 볼륨에 ext4 파일 시스템이 있습니다. 다양한 성능 조정 전략을 테스트하고 있었는데 이런 아이디어가 떠올랐습니다. pvmove는 개별 확장 영역과 확장 영역을 모두 이동할 수 있으므로 특정 파일(이론적으로 데이터베이스의 백업 파일 또는 자주 액세스하는 대규모 파일 공유일 수 있음)을 보유하는 물리적 확장 영역을 파악하고 이를 특정 위치 저장소로 이동할 수 있는 방법이 있습니까? 장치(예를 들어 동일한 LVM 볼륨 그룹에 일반 HDD와 SSD 드라이브가 있음)?

"filefrag"를 사용하려고 생각했지만 범위 번호를 순서대로 사용해야 하는지 100% 확신할 수 없다는 생각이 들었습니다. 따라서 파일이 표시되는 ext4의 섹터 수를 아는 것이 반드시 계산할 수 있는 것은 아닙니다. it out 파일이 실제로 위치한 범위 번호/볼륨입니다.

어떤 아이디어가 있나요?

답변1

두 가지 주요 구성 요소는 LV에 있는 파일의 물리적 위치와 장치에 있는 LV의 물리적 위치를 hdparm --fibmap file알려준다는 것 입니다.lvs -o +seg_pe_ranges,vg_extent_size

나머지는 수학이다.

예를 들면 다음과 같습니다.

# hdparm --fibmap linux-3.8.tar.bz2 

linux-3.8.tar.bz2:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0     288776     298511       9736
     4984832     298520     298623        104
     5038080     298640     298695         56
     5066752     298736     298799         64
     5099520     298824     298895         72
     [...]

이것이 왜 그렇게 단편화되었는지 모르겠습니다. 다운로드하려면 wget을 사용하십시오. 좋은 예가 될 수 있습니다. 보시다시피 어떤 방식으로든 스크립트를 작성하지 않으면 적어도 조각난 파일의 경우 두통이 생길 수 있기 때문입니다. 첫 번째 세그먼트 288776-298511(9736 섹터)만 사용합니다. 512바이트 섹터가 아니기 때문에 개수가 잘못되었습니다.

먼저 다음 데이터가 실제로 올바른지 확인하세요.

# dd if=linux-3.8.tar.bz2 bs=512 skip=0 count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0506548 s, 98.4 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

# dd if=/dev/lvm/src bs=512 skip=288776 count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.123292 s, 40.4 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

휘이. 똑같아서 올바른 위치에서 LV-src를 읽고 있습니다. 현재 소스 LV는 어디에 있습니까?

# lvs -o +seg_pe_ranges,vg_extent_size
  LV          VG   Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert PE Ranges             Ext   

[...]
 src         lvm  -wi-ao---   4.00g                                            /dev/dm-1:5920-6047   32.00m
[...]

이제 심심해요. 이 LV는 조각난 게 아니에요. 여기에는 두통이 없습니다. 그래도.

src는 /dev/dm-1에 있으며 PE 5920에서 시작하여 PE 6047에서 끝난다고 나와 있습니다. PE 크기는 32MiB입니다.

그럼 /dev/dm-1에서 직접 동일한 내용을 읽을 수 있는지 살펴보겠습니다. 수학적으로 이것은 이전에 512바이트 블록 크기를 사용했기 때문에 약간 모호합니다... :-/ 하지만 저는 게을러서 MiB를 계산하고 512로 나눴습니다! 하아! :-디

# dd if=/dev/dm-1 bs=512 skip=$((1024*1024/512 * 32 * 5920 + 288776)) count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0884709 s, 56.3 MB/s
3858a4cd75b1cf6f52ae2d403b94a685  -

쉿. 이것은 우리가 찾고 있는 것이 아닙니다. 무엇이 잘못되었나요? 아! LVM 메타데이터와 쓰레기를 저장하기 위해 PV 시작 부분에 LVM 점유 오프셋을 추가하는 것을 잊었습니다. 일반적으로 MiB가 정렬되어 있으므로 다른 MiB를 추가하면 됩니다.

# dd if=/dev/dm-1 bs=512 skip=$((1024*1024/512 * 32 * 5920 + 288776 + 1024*1024/512)) count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0107592 s, 463 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

거기 있어요.

관련 정보