透視BlueStore存儲結構：如何根據文件名從裸盤提取文件內容

在FileStore下，用戶文件通過切分對象塊後最終存放在了單機文件系統（xfs 、ext4等）中，咱們能夠較容易地找到這些對象塊對應的文件，而後提取這些對象塊文件後組裝成用戶文件。然而，BlueStore是構建在裸盤上的，沒有文件之說，咱們提取用戶文件時就須要知道用戶文件的坐落在裸盤的哪些空間（位置+大小：offset + length）上。下面筆者就介紹下筆者是怎麼提取BlueStore中的文件的~

1、須要瞭解的一些概念

若是筆者理解有誤，請留言指正~

概念	解釋
onode	每一個對象有個onode
lextent	邏輯extent
extent_map	存放 lextent 的map
extent_map shard	extent map較大時切分shard
blob	lextent佔據blob的一段或這所有 ，blob內能夠有多個lextent
pextent	物理extent，blob由一個或多個 pextent 組成  pextent 含字段 offset+length，表明裸盤的一段空間

幾個概念的關係如圖：

此圖源於網絡（http://www.sysnote.org/2016/08/19/ceph-bluestore/），若有冒犯，請聯繫筆者刪除~

 

 

2、使用 ceph-kvstore-tool 工具得到用戶文件位置

集羣中有名爲ceph-osd.0.log的文件：

[root@s131 /data]# ls -i /cephfs 1099511627776 ceph-osd.0.log 1099511627777 test 

獲取該文件的十六進制inode號：

[root@s131 /data]# printf %llx 1099511627776 10000000000 

使用 ceph osd map fs_d 10000000000.00000000 命令能夠取得該對象所在的osd ${OSDID}，經過 ceph-kvstore-tool 工具查看其 onode 和 onode的extent_map的shard：

[root@s131 /data]# ceph-kvstore-tool bluestore-kv /data/lib/ceph/osd/ceph-${OSDID} list O 2>/dev/null |grep 10000000000.00000000 O %7f%80%00%00%00%00%00%00%02%0c%f6%ad%0f%2110000000000.00000000%21%3d%ff%ff%ff%ff%ff%ff%ff%fe%ff%ff%ff%ff%ff%ff%ff%ffo O %7f%80%00%00%00%00%00%00%02%0c%f6%ad%0f%2110000000000.00000000%21%3d%ff%ff%ff%ff%ff%ff%ff%fe%ff%ff%ff%ff%ff%ff%ff%ffo%00%00%00%00x O %7f%80%00%00%00%00%00%00%02%0c%f6%ad%0f%2110000000000.00000000%21%3d%ff%ff%ff%ff%ff%ff%ff%fe%ff%ff%ff%ff%ff%ff%ff%ffo%00%08%00%00x O %7f%80%00%00%00%00%00%00%02%0c%f6%ad%0f%2110000000000.00000000%21%3d%ff%ff%ff%ff%ff%ff%ff%fe%ff%ff%ff%ff%ff%ff%ff%ffo%00%10%00%00x O %7f%80%00%00%00%00%00%00%02%0c%f6%ad%0f%2110000000000.00000000%21%3d%ff%ff%ff%ff%ff%ff%ff%fe%ff%ff%ff%ff%ff%ff%ff%ffo%00%18%00%00x O %7f%80%00%00%00%00%00%00%02%0c%f6%ad%0f%2110000000000.00000000%21%3d%ff%ff%ff%ff%ff%ff%ff%fe%ff%ff%ff%ff%ff%ff%ff%ffo%00%20%00%00x O %7f%80%00%00%00%00%00%00%02%0c%f6%ad%0f%2110000000000.00000000%21%3d%ff%ff%ff%ff%ff%ff%ff%fe%ff%ff%ff%ff%ff%ff%ff%ffo%00%28%00%00x O %7f%80%00%00%00%00%00%00%02%0c%f6%ad%0f%2110000000000.00000000%21%3d%ff%ff%ff%ff%ff%ff%ff%fe%ff%ff%ff%ff%ff%ff%ff%ffo%00%2a%10%00x 

第一個kv對象是onode，後面每個kv對象是onode的extent_map的一個shard
使用 ceph-kvstore-tool 的get命令能夠將kv對象保存成文件：

ceph-kvstore-tool  bluestore-kv  /data/lib/ceph/osd/ceph-0 get O %7f%80%00%00%00%00%00%00%02%0c%f6%ad%0f%2110000000000.00000000%21%3d%ff%ff%ff%ff%ff%ff%ff%fe%ff%ff%ff%ff%ff%ff%ff%ffo out onode_out_file 

要獲取用戶的存儲位置，就須要得到onode最終存儲在哪些pextent上，而這個信息是存儲在onode的extent_map中的，咱們須要將這些信息加載到內存，而後dump出來

筆者對 ceph-kvstore-tool 進行修改，在get onode時，將onode及其extent_map都加載到內存中，而後dump出來：

_dump_onode 0x7f67c86bf440 #2:0cf6ad0f:::10000000000.00000000:head# nid 151669 size 0x2a1a47 (2759239) expected_object_size 0 expected_write_size 0 in 7 shards, 1 spanning blobs _dump_onode attr _ len 275 _dump_onode attr snapset len 35 _dump_extent_map shard 0x0(0x211 bytes) (loaded) _dump_extent_map shard 0x80000(0x213 bytes) (loaded) _dump_extent_map shard 0x100000(0x213 bytes) (loaded) _dump_extent_map shard 0x180000(0x213 bytes) (loaded) _dump_extent_map shard 0x200000(0x213 bytes) (loaded) _dump_extent_map shard 0x280000(0x97 bytes) (loaded) _dump_extent_map shard 0x2a1000(0x9 bytes) (loaded) _dump_extent_map 0x0~80000: 0x0~80000 Blob(0x7f67c87004c0 blob([0x86d626d000~80000] csum crc32c/0x1000) use_tracker(0x80*0x1000 0x[1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000,1000]) SharedBlob(0x7f67c8700140 sbid 0x0)) _dump_extent_map csum: [a9c1d499,82e5a14b,13d41153,5d2c92ac,bd486ca7,69b734b3,bbd4506b,5c78934,23a7ec86,71cd4025,da049035,3b335b95,3aaad68e,c108d427,64464011,4e852c8b,f105f7cf,97c530a5,990131c3,53abee5f,eb2a752e,f46c6204,a02cd25e,a0edcf8f,806f4051,6edf9661,3a6a9b6e,46839e5d,47a8fe0,e1fbbc93,2881e5c,ff0c1c78,120aeef4,b871a43b,311a829a,a086216e,690f7afc,2c4fcfc8,5ca3103d,1b26aedc,75e29d22,c6ef70c2,b554bde1,ad70d878,55acfc75,1adb3a0a,8ac031ab,5392bb48,6548b760,7b8223e,9bf5dd1b,8935c0b,d5ba7870,4bb04662,b37a21fc,ab36345c,2277149a,fbb73550,2dc74707,bfafd22b,28981f79,950972b1,d6bbde66,74b66358,81c50f84,716677d5,2b6ef5d2,996752fd,b99bf360,24715cce,d62dfb8,b11bd85c,3136a56a,882e8c4,ecf2eb0c,16926e73,d339b6de,d17d8613,337ca950,cad27fa6,f2efd4e7,bb0b23ce,6c8b014b,209144b7,86da06c3,8e6fa11e,463ec5a,c1b83c22,187d0b9c,15931b79,5dda6148,a89ab9ae,563f9db5,33902e1,cde965c4,859ac4e3,3a2d5134,9a824e29,6e9626a8,f9c58152,647d262a,955ca05d,baaa6a85,58e3133b,a19af4f0,57cdb970,fa0c6a09,551ac600,8400f2b5,2885abc7,9ce677f1,4d3d5310,b8f464a,2693ec2b,bfedcacc,6a302160,2e312a4f,362e6430,9c0d1984,cba58e72,9fe69d47,5ae2db10,f5ebd276,9dbbbc83,a4df126a,f4b63496,4e0034cb,1df47ea7] 

提取出關鍵的pextent的信息：

[root@s131 /data]# cat onode_dump |grep "blob(" |awk '{print $5" "$6" "$7}' blob([0x86d626d000~80000] csum crc32c/0x1000) blob([0x86d62ed000~80000] csum crc32c/0x1000) blob([0x86d636d000~80000] csum crc32c/0x1000) blob([0x86d63ed000~80000] csum crc32c/0x1000) blob([0x86d646d000~80000] csum crc32c/0x1000) blob([0x86d64ed000~21000] csum crc32c/0x1000) spanning 0 blob([!~21000,0x86d650e000~1000] 

[0x86d626d000~80000]表示的是blob中的pextent的數組，0x86d626d000是pextent在裸盤上的offset，80000爲其長度
因爲筆者的環境比較乾淨，這些blob的pextent在裸盤上是連續的，用戶文件的長度是已知的，爲2759239，咱們能夠經過以下方式提取出用戶文件

[root@s131 /data]# printf %lld 0x86d626d000 579118485504 [root@s131 /data]# dd if=/dev/sdb2 of=test_onode_dump bs=1 count=2759239 skip=579118485504 [root@s131 /data]# md5sum /cephfs/ceph-osd.0.log e07a2ab39136190a9550a3b07ca9efd9 /cephfs/ceph-osd.0.log [root@s131 /data]# md5sum test_onode_dump e07a2ab39136190a9550a3b07ca9efd9 test_onode_dump 

提取出的文件的md5跟直接經過/cephfs訪問獲得的mds5一致，提早用戶文件數據完畢: )

3、關注筆者