Comment savoir ce qui est mis en cache par dm-cache?

J'utilise dm-cache avec succès depuis un bon moment maintenant. Maintenant, je voudrais savoir quels fichiers sont actuellement dans le cache. Je comprends que dm-cache fonctionne avec des blocs, pas avec des fichiers, mais comme il y a un système de fichiers au-dessus, il devrait être possible en théorie de traduire cela en (parties de) fichiers mis en cache.

Bien sûr, je me soucie d'une solution pratique: comment puis-je répertorier ce qui se trouve actuellement dans dm-cache?

Selon la documentation du noyau , dm-cachea des métadonnées, qui sont une famille avec des métadonnées de provisionnement fin:

La cible réutilise la bibliothèque de métadonnées utilisée dans la bibliothèque d'allocation dynamique.

Ainsi, vous pouvez utiliser le thin-provisioning-toolspackage, qui fournit cache_dump.

Cependant, l'utilisation de cet outil n'est pas très simple. Le fichier README suggère que vous devez d'abord prendre un instantané de l'appareil , mais même ainsi, je ne pouvais pas du tout le faire fonctionner.

# 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.

J'ai donc fini par faire quelque chose de bizarre à la place:

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

Résultat:

<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"/>

Alors, qu'avons-nous ici. Une taille de bloc de "128" (secteurs) et le premier bloc ("0") dans le périphérique de cache sont censés être identiques au bloc "163832" du périphérique d'origine. Vérifions si cela a du sens.

Pour <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

Pour <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

Cela me semble correct. Tout le reste est le même vieux "savoir quel fichier est où". Il peut être fait avec filefrag, hdparm --fibmapou des outils spécifiques du système de fichiers comme debugfs icheck. Le même vieux ne veut malheureusement pas dire simple ...

C'est l'approche très stupide et très manuelle:

# 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

265120est à l'intérieur 163856..311703donc c'est le fichier! Ou est-ce?

# 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

L'ADN correspond, le timing fonctionne, tout se vérifie.

Bien sûr, je me soucie d'une solution pratique: comment puis-je répertorier ce qui se trouve actuellement dans dm-cache?

Malheureusement, ce n'est pas très pratique tant que vous ne l'avez pas écrit à chaque étape. Je n'ai pas pu trouver de script prêt à l'emploi. Donc, tout ce que je peux vous offrir à ce stade, ce sont les ingrédients nécessaires. Désolé :-)