我已经成功使用 dm-cache 一段时间了。现在我想知道缓存中当前有哪些文件。我知道 dm-cache 适用于块,而不是文件,但由于上面有一个文件系统,理论上应该可以将其转换为正在缓存的(部分)文件。
当然,我关心一个实用的解决方案:如何列出 dm-cache 中当前的内容?
答案1
根据内核文档,dm-cache
有元数据,这是一个具有精简配置元数据的家族:
目标重用自动精简配置库中使用的元数据库。
因此,您可以使用该thin-provisioning-tools
包,它提供了cache_dump
.
然而,这个工具的使用并不是很简单。自述文件建议您必须首先对设备进行快照,但即便如此,我根本无法让它工作。
# 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 中当前的内容?
不幸的是,这不太实用,除非您为每一步都编写脚本。我还没有找到一个现成的脚本。所以此时我能为您提供的只是必要的成分。对不起 :-)