dm-cache가 무엇을 캐싱하는지 아는 방법?

나는 꽤 오랫동안 dm-cache를 성공적으로 사용하고 있습니다. 이제 캐시에 어떤 파일이 있는지 알고 싶습니다. dm-cache는 파일이 아닌 블록과 함께 작동한다는 것을 이해하지만, 파일 시스템이 위에 있기 때문에 이론 상으로는 이것을 캐시되는 파일의 일부로 변환 할 수 있어야합니다.

물론 실용적인 해결책에 관심이 있습니다. 현재 dm-cache에있는 것을 어떻게 나열합니까?

linux cache ssd

— 파비안
소스

커널 문서에 따르면 , dm-cache씬 프로비저닝 (thin-provisioning) 메타 데이터를 하나 개의 가족 메타 데이터를 가지고 :

대상은 씬 프로비저닝 라이브러리에서 사용 된 메타 데이터 라이브러리를 재사용합니다.

따라서을 thin-provisioning-tools제공 하는 패키지 를 사용할 수 있습니다 cache_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에있는 것을 어떻게 나열합니까?

불행히도, 이것은 모든 단계에서 스크립트를 작성하기 전까지는 실용적이지 않습니다. 사용할 준비가 된 스크립트를 찾을 수 없었습니다. 이 시점에서 제가 제공 할 수있는 것은 필요한 재료입니다. 죄송합니다 :-)

— 서리
소스