কার্নেল ডকুমেন্টেশন অনুসারে , 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
আমার কাছে ভালই মনে হচ্ছে. অন্য সব কিছুই একই পুরানো "কোন ফাইলটি কোথায় তা খুঁজে বের করুন"। এটি 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
ডিএনএ মেলে, সময় কাজ করে, সবকিছু চেক আউট করে।
অবশ্যই আমি একটি ব্যবহারিক সমাধান সম্পর্কে যত্ন: আমি কীভাবে তালিকাভুক্ত করতে পারি ডিএম-ক্যাশে?
দুর্ভাগ্যক্রমে, যতক্ষণ না আপনি এটিকে প্রতিটি ধাপে স্ক্রিপ্ট করেন until আমি এর জন্য ব্যবহারের জন্য প্রস্তুত স্ক্রিপ্টটি সক্ষম করতে পারিনি। সুতরাং আমি আপনাকে এই মুহুর্তে যে সমস্ত অফার করতে পারি তা হ'ল প্রয়োজনীয় উপাদান। দুঃখিত :-)