Upower внезапно перестал работать

Согласно документации ядра , dm-cacheимеет метаданные, которые представляют собой одно семейство с тонкими -метаданными обеспечения:

The target reuses the metadata library used in the thin-provisioning library.

Таким образом, вы можете использовать пакет 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

Результат:

  
    
    
    
   ...
    
    
    

Итак, что мы имеем здесь. Предполагается, что размер блока «128» (секторов ), а первый блок («0» )в кэш-устройстве идентичен блоку «163832» исходного устройства. Давайте проверим, есть ли в этом вообще смысл.

Для:

# 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

Для:

# 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

ДНК совпадает, время работает, все совпадает.

Of course I care about a practical solution: How can I list what is currently in dm-cache?

К сожалению, это не очень практично, пока вы не пропишете каждый шаг этого пути. Я не смог найти готовый ---скрипт для его использования. Так что все, что я могу предложить вам на данный момент, это необходимые ингредиенты. Извините:-)