การพิจารณาหมายเลข LVM Extent สำหรับไฟล์ที่กำหนด

ขณะนี้ฉันกำลังฝึกการบ้านที่ไม่เกี่ยวข้องกับการทำงาน ฉันมีระบบไฟล์ ext4 นั่งอยู่บนโลจิคัลวอลุ่ม ฉันกำลังทดสอบกลยุทธ์การปรับแต่งประสิทธิภาพที่แตกต่างกันและแนวคิดนี้เกิดขึ้นกับฉัน เนื่องจาก pvmove สามารถย้ายส่วนบุคคลและช่วงของขอบเขตได้มีวิธีการแมปสิ่งที่ extents ทางกายภาพเก็บไฟล์เฉพาะ (ในทางทฤษฎีมันสามารถสำรองไฟล์สำหรับฐานข้อมูลหรือแชร์ไฟล์ขนาดใหญ่ที่เข้าถึงได้ทั่วไป) และย้ายไปยังส่วนใดส่วนหนึ่ง อุปกรณ์จัดเก็บข้อมูล (ตัวอย่างเช่นฉันมี HDD ปกติและไดรฟ์ SSD ในกลุ่มวอลุ่ม LVM เดียวกัน)

ฉันคิดว่าการใช้ "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
[...]

ตอนนี้มันน่าเบื่อเลเวลนี้ไม่กระจัดกระจาย ไม่มีอาการปวดหัวที่นี่ อย่างไรก็ตาม.

มันบอกว่า src เปิด / dev / dm-1 และเริ่มที่ PE 5920 และสิ้นสุดที่ PE 6047 และขนาด PE คือ 32 MiB

ลองดูว่าเราสามารถอ่านสิ่งเดียวกันจาก / dev / dm-1 ได้โดยตรงหรือไม่ คณิตศาสตร์ฉลาดนี่เป็นสิ่งที่น่ายินดีเล็กน้อยเนื่องจากเราใช้บล็อกขนาด 512 ไบต์ก่อนหน้านี้ ... : - / แต่ฉันขี้เกียจดังนั้นฉันจะคำนวณ MiB แล้วหารด้วย 512! ฮา! :-D

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

ที่นั่นคุณมีมัน