주어진 파일에 대한 LVM 범위 번호 결정

저는 현재 업무와 관련이없는 숙제를하고 있습니다. 논리 볼륨에 ext4 파일 시스템이 있습니다. 다른 성능 조정 전략을 테스트 중이며이 아이디어가 나에게 일어났습니다. pvmove는 개별 범위와 범위의 범위를 이동할 수 있기 때문에 특정 파일을 보유하는 물리적 범위가 무엇인지 (이론적으로 데이터베이스의 파일을 백업하거나 일반적으로 액세스하는 큰 파일 공유 일 수 있음) 매핑하고이를 특정 범위로 이동할 수있는 방법이 있습니까? 스토리지 장치 (예 : 동일한 LVM 볼륨 그룹에 일반 HDD 및 SSD 드라이브가 있음)?

나는 "filefrag"를 사용하려고 생각했지만 익스텐트 번호가 반드시 순차적으로 사용되는지 100 %가 아닌 것으로 나타났습니다 (ext4의 얼마나 많은 섹터가 파일을 볼 수 있는지 아는 것은 아닙니다. 파일이 실제로 어느 정도의 숫자 / 볼륨에 있는지 파악합니다.

어떤 아이디어?

두 가지 주요 구성 요소는 hdparm --fibmap file파일이 LV 내에서 실제로 lvs -o +seg_pe_ranges,vg_extent_size어디에 있는지, LV가 장치에서 실제로 어디에 있는지를 알려줍니다.

나머지는 수학입니다.

예를 들어,

# 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  -

Wheeee. 그것은 동일하므로 우리는 올바른 장소에서 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  -

거기 있어요