如何知道dm-cache缓存了什么?


10

我已经成功使用dm-cache一段时间了。现在,我想知道当前在缓存中的文件。我知道dm-cache适用于块,而不适用于文件,但是由于上面有一个文件系统,从理论上讲应该可以将其转换为要缓存的文件(的一部分)。

当然,我关心一个实际的解决方案:如何列出dm-cache中当前的内容?

Answers:


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

在我看来很好。其他所有内容都与旧的“找出哪个文件在哪里”相同。这是可以做到的filefraghdparm --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中当前的内容?

不幸的是,在您编写脚本的所有步骤之前,这不是很实用。我还没有找到一个现成的脚本。因此,在这一点上,我所能提供的就是必要的成分。对不起:-)

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.