จะรู้ได้อย่างไรว่า dm-cache ถูกแคชไว้อย่างไร?

ฉันใช้ dm-cache เรียบร้อยแล้วพักหนึ่งแล้ว ตอนนี้ฉันอยากจะรู้ว่าไฟล์ใดที่อยู่ในแคช ฉันเข้าใจว่า dm-cache ใช้งานได้กับบล็อกไม่ใช่ไฟล์ แต่เนื่องจากมีระบบไฟล์ด้านบนจึงควรมีความเป็นไปได้ในทางทฤษฎีในการแปลไฟล์นี้เป็นส่วนต่างๆของแคช

แน่นอนฉันสนใจโซลูชันที่ใช้งานได้จริง: ฉันจะแสดงรายการสิ่งที่อยู่ใน dm-cache ได้อย่างไร

ตามเอกสาร kernel , dm-cacheมีข้อมูลเมตาซึ่งเป็นหนึ่งในครอบครัวที่มีเมตาดาต้าบางการตั้งสำรอง:

เป้าหมายจะใช้ไลบรารี metadata ที่ใช้ในไลบรารี thin-provisioning อีกครั้ง

ดังนั้นคุณสามารถใช้แพคเกจที่ให้บริการthin-provisioning-toolscache_dump

อย่างไรก็ตามการใช้เครื่องมือนี้ไม่ได้ตรงไปตรงมามาก README แนะนำให้คุณถ่ายภาพอุปกรณ์ก่อนแต่ถึงอย่างนั้นฉันก็ไม่สามารถทำให้มันใช้งานได้เลย

# cache_dump /dev/mapper/foo-bar_cmeta
syscall 'open' failed: Device or resource busy
Note: you cannot run this tool with these options on live metadata.

ดังนั้นฉันจึงลงเอยทำสิ่งที่แปลกแทน:

# cp /dev/mapper/foo-bar_cmeta /dev/shm
# losetup --find --show /dev/shm/foo-bar_cmeta
/dev/loop1
# cache_dump /dev/loop1

ผลลัพธ์:

<superblock uuid="" block_size="128" nr_cache_blocks="16384" policy="smq" hint_width="4">
  <mappings>
    <mapping cache_block="0" origin_block="163832" dirty="false"/>
    <mapping cache_block="1" origin_block="163833" dirty="false"/>
    <mapping cache_block="2" origin_block="163834" dirty="false"/>
    ...
    <mapping cache_block="5295" origin_block="16568" dirty="false"/>
    <mapping cache_block="5296" origin_block="16569" dirty="false"/>
    <mapping cache_block="5297" origin_block="16570" dirty="false"/>

เรามีอะไรที่นี่ ขนาดบล็อก "128" (เซ็กเตอร์) และบล็อกแรก ("0") ในอุปกรณ์แคชควรจะเหมือนกับบล็อก "163832" ของอุปกรณ์ต้นทาง ลองตรวจสอบดูว่ามันสมเหตุสมผลหรือไม่

สำหรับ<mapping cache_block="0" origin_block="163832" dirty="false"/>:

# hexdump -C --skip $((512*128*0)) -n 32 /dev/mapper/foo-bar_cdata 
00000000  61 51 a3 09 88 ad 72 f8  6a 90 7f 93 fd 64 c0 c3  |aQ....r.j....d..|
00000010  e4 01 c5 cf e1 ba 37 53  d0 d8 06 cf 3a da d8 2d  |......7S....:..-|
00000020
# hexdump -C --skip $((512*128*163832)) -n 32 /dev/mapper/foo-bar_corig 
27ff80000  61 51 a3 09 88 ad 72 f8  6a 90 7f 93 fd 64 c0 c3  |aQ....r.j....d..|
27ff80010  e4 01 c5 cf e1 ba 37 53  d0 d8 06 cf 3a da d8 2d  |......7S....:..-|
27ff80020

สำหรับ<mapping cache_block="5297" origin_block="16570" dirty="false"/>:

# hexdump -C --skip $((512*128*5297)) -n 32 /dev/mapper/foo-bar_cdata 
14b10000  68 72 65 61 64 5d 3a 20  56 2f 6e 73 48 74 74 70  |hread]: V/nsHttp|
14b10010  20 30 30 30 30 33 44 31  30 3a 20 30 33 20 44 37  | 00003D10: 03 D7|
14b10020
# hexdump -C --skip $((512*128*16570)) -n 32 /dev/mapper/foo-bar_corig 
40ba0000  68 72 65 61 64 5d 3a 20  56 2f 6e 73 48 74 74 70  |hread]: V/nsHttp|
40ba0010  20 30 30 30 30 33 44 31  30 3a 20 30 33 20 44 37  | 00003D10: 03 D7|
40ba0020

ดูดีกับผม. ทุกอย่างอื่นเป็น "รูปเก่าที่ไฟล์" ก็สามารถทำได้ด้วยfilefrag, หรือเครื่องมือระบบแฟ้มที่เฉพาะเจาะจงเช่นhdparm --fibmap debugfs icheckเก่าเหมือนกันน่าเสียดายที่ไม่ได้หมายความว่าง่าย ...

นี่เป็นวิธีที่โง่มากและทำด้วยมืออย่างมาก:

# echo $((512*128*16570/4096))
265120
# filefrag -v -e *
[...]
File size of firefox-network.log-main.2270 is 605582660 (147848 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..  147847:     163856..    311703: 147848:             last,eof

265120อยู่ภายใน163856..311703ดังนั้นนี่คือไฟล์! หรือมันคืออะไร?

# hexdump -C --skip $((512*128*16570-163856*4096)) -n 32 firefox-network.log-main.2270 
18b90000  68 72 65 61 64 5d 3a 20  56 2f 6e 73 48 74 74 70  |hread]: V/nsHttp|
18b90010  20 30 30 30 30 33 44 31  30 3a 20 30 33 20 44 37  | 00003D10: 03 D7|
18b90020

การจับคู่ DNA เวลาทำงานทุกอย่างตรวจสอบ

แน่นอนฉันสนใจโซลูชันที่ใช้งานได้จริง: ฉันจะแสดงรายการสิ่งที่อยู่ใน dm-cache ได้อย่างไร

น่าเสียดายที่นี่ไม่สามารถใช้งานได้จริงจนกว่าคุณจะเขียนสคริปต์ทุกขั้นตอน ฉันไม่สามารถค้นหาสคริปต์ที่พร้อมใช้งานได้ ดังนั้นทั้งหมดที่ฉันสามารถเสนอให้คุณ ณ จุดนี้เป็นส่วนผสมที่จำเป็น ขออภัย :-)