私はしばらくdm-cacheを正常に使用してきました。さて、現在のキャッシュにどのファイルがあるのか知りたいです。私はdm-cacheがファイルではなくブロックで動作することを知っていますが、一番上にファイルシステムがあるので、理論的にそれをキャッシュされたファイル(一部)に変換することが可能でなければなりません。
もちろん、私は実際の解決策であるdm-cacheの現在の内容をリストする方法に興味があります。
答え1
カーネル文書によると、dm-cache
メタデータがある場合は、シンプロビジョニングメタデータを含むスイートです。
ターゲットは、シンプロビジョニングリポジトリで使用されているメタベースを再利用します。
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
いいと思います。他のすべては、「どのファイルがどこにあるかを調べる」と同じです。これは、.NET Frameworkなどのファイルシステム関連のツールを使用して実行できます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の現在の内容をリストする方法に興味があります。
残念ながら、すべての手順をスクリプトで記述しない限り、これは実用的ではありません。まだ準備されたスクリプトが見つかりませんでした。だから今私ができることは必要な材料だけです。申し訳ありません:-)