Corrupted journal resource cluster metadata

VMFS는 Filesystem이기 때문에 On-disk 와 In-memory 영역으로 구분할 수 있으며, On-disk에 Corruption이 발생한 경우 VMFS 상태 확인 및 조치 도구인 VOMA와 Hexdump를 이용해서 어느 부분에 문제가 있고 문제의 원인 분석을 위해서는 어떻게 접근해야 하는지에 대해서 알아보겠습니다.

 

[문제 증상]

 

[분석 내용]

1. vmkernel.log

## vCenter에서 기록된 메시지와 동일한 내용이 vmkernel.log에서 확인

2023-06-08T08:21:02.601Z cpu37:2098380)WARNING: Res3: 7066: Volume 5d6dca3e-15e5f0c2-5a55-54802851f0b6 ("xxx_16") might be damaged on the disk. Resource cluster metadata corruption has been detected. 2023-06-08T08:22:24.714Z cpu37:2098380)WARNING: Res3: 7066: Volume 5c980192-fba02734-13c6-54802851f0b6 ("xxx_07") might be damaged on the disk. Resource cluster metadata corruption has been detected.   2023-05-15T02:10:27.121Z cpu37:2098380)WARNING: [type 6] Invalid signature: 0 for clusterNum: 11887. 2023-05-15T02:10:27.121Z cpu37:2098380)WARNING: [type 6] Invalid signature: 0 for clusterNum: 11887. 2023-05-15T02:10:27.121Z cpu37:2098380)WARNING: Res3: 7066: Volume 5c980192-fba02734-13c6-54802851f0b6 ("xxx_07") might be damaged on the disk. Resource cluster metadata corruption has been detected. 2023-05-15T02:10:27.121Z cpu37:2098380)WARNING: FS3: 608: VMFS volume xxx_07/5c980192-fba02734-13c6-54802851f0b6 on naa.60060e80072c500000302c5000001041:1 has been detected corrupted 2023-05-15T02:10:27.121Z cpu37:2098380)FS3: 610: While filing a PR, please report the names of all hosts that attach to this LUN, tests that were running on them, 2023-05-15T02:10:27.121Z cpu37:2098380)FS3: 634: and upload the dump by `voma -m vmfs -f dump -d /vmfs/devices/disks/naa.60060e80072c500000302c5000001041:1 -D X` 2023-05-15T02:10:27.121Z cpu37:2098380)FS3: 641: where X is the dump file name on a DIFFERENT volume 2023-05-15T02:10:27.121Z cpu37:2098380)FS3: 374: FS3RCMetaVMFS6 14495964182998785 2653396435730432 0 646894212 11887 0 0 0 0 2023-05-15T02:10:27.121Z cpu37:2098380)FS3: 379: 0 0 0 0 24 0 1106 12337 0 0 2023-05-15T02:10:27.121Z cpu37:2098380)FS3: 384: 3977015120021238062 3617582 00000000-00000000-0000-000000000000 2023-05-15T02:10:27.121Z cpu37:2098380)FS3: 388: 0 0 0 0 0 0 0 0 2023-05-15T02:10:27.121Z cpu37:2098380)FS3: 395: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2023-05-15T02:10:27.121Z cpu37:2098380)FS3: 399: 0 0 2023-05-15T02:10:27.121Z cpu37:2098380)FS3: 405: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

 

2. vmkfstools

## 문제가 발생한 Datastore의 Partition 구성을 확인

vmkfstools_-P--v-10-vmfsvolumesxxx_07.txt       VMFS-6.82 (Raw Major Version: 24) file system spanning 1 partitions.     File system label (if any): xxx_07     Mode: public ATS-only     Capacity 3298266447872 (3145472 file blocks * 1048576), 3296704069632 (3143982 blocks) avail, max supported file size 70368744177664     Volume Creation Time: Sun Mar 24 22:15:46 2019     Files (max/free): 16384/16372     Ptr Blocks (max/free): 0/0     Sub Blocks (max/free): 16384/16379     Secondary Ptr Blocks (max/free): 256/255     File Blocks (overcommit/used/overcommit %): 0/1490/0     Ptr Blocks  (overcommit/used/overcommit %): 0/0/0     Sub Blocks  (overcommit/used/overcommit %): 0/5/0     Large File Blocks (total/used/file block clusters): 6144/0/256     Volume Metadata size: 1555628032     Disk Block Size: 512/512/0     UUID: 5c980192-fba02734-13c6-54802851f0b6     Logical device: 5c980192-eaa7c660-37f9-54802851f0b6     Partitions spanned (on "lvm"):             naa.60060e80072c500000302c5000001041:1 ### <-- !!     Unable to connect to vaai-nasd socket [No such file or directory]     Is Native Snapshot Capable: NO     OBJLIB-LIB: ObjLib cleanup done.     WORKER: asyncOps=0 maxActiveOps=0 maxPending=0 maxCompleted=0     vmkfstools_-P--v-10-vmfsvolumesxxx_16.txt       VMFS-6.82 (Raw Major Version: 24) file system spanning 1 partitions.     File system label (if any): xxx_16     Mode: public ATS-only     Capacity 3298266447872 (3145472 file blocks * 1048576), 3296704069632 (3143982 blocks) avail, max supported file size 70368744177664     Volume Creation Time: Tue Sep  3 02:04:46 2019     Files (max/free): 16384/16369     Ptr Blocks (max/free): 0/0     Sub Blocks (max/free): 16384/16377     Secondary Ptr Blocks (max/free): 256/255     File Blocks (overcommit/used/overcommit %): 0/1490/0     Ptr Blocks  (overcommit/used/overcommit %): 0/0/0     Sub Blocks  (overcommit/used/overcommit %): 0/7/0     Large File Blocks (total/used/file block clusters): 6144/0/256     Volume Metadata size: 1555628032     Disk Block Size: 512/512/0     UUID: 5d6dca3e-15e5f0c2-5a55-54802851f0b6     Logical device: 5d6dca3e-042f9e82-d646-54802851f0b6     Partitions spanned (on "lvm"):             naa.60060e80072c500000302c5000001045:1 ### <-- !!     Unable to connect to vaai-nasd socket [No such file or directory]     Is Native Snapshot Capable: NO     OBJLIB-LIB: ObjLib cleanup done.     WORKER: asyncOps=0 maxActiveOps=0 maxPending=0 maxCompleted=0

 

3. partedUtil

## vmkfstools 명령어 결과를 partedUtil 결과를 통해 검증

partedUtil.sh.txt       Device:  /vmfs/devices/disks/naa.60060e80072c500000302c5000001041     Partition table:     gpt     401024 255 63 6442450944     1 2048 6442450910 AA31E02A400F11DB9590000C2911D1B8 vmfs 0           Usable sectors:     34 6442450910             Device:  /vmfs/devices/disks/naa.60060e80072c500000302c5000001045     Partition table:     gpt     401024 255 63 6442450944     1 2048 6442450910 AA31E02A400F11DB9590000C2911D1B8 vmfs 0           Usable sectors:     34 6442450910

 

4. Livedump 수집

## 문제가 발생한 Datastore의 Filesystem 상태 점검을 위해 VOMA 결과 수집

#voma -l -f dump -d /vmfs/devices/disks/naa.60060e80072c500000302c5000001045:1 -D xxx_16_voma_dump_new #voma -l -f dump -d /vmfs/devices/disks/naa.60060e80072c500000302c5000001041:1 -D xxx_07_voma_dump_new

 

5. extraction of VOMA dump

# voma-static -x xxx_07_voma_dump_new -Z xxx_07_voma_dump_new.file # voma-static -x xxx_16_voma_dump_new -Z xxx_16_voma_dump_new.file

 

6. inspecting VOMA dump

## 수집된 VOMA 결과 파일을 확인해보면, 여러 검사 단계 중 "Phase 1: Checking VMFS header and resource files"에서 문제가 있는 것으로 확인

## Phase1에서 점검하는 내용 중 Resource File이 있는데 이 중 JB(Journal Block) Resource File 내의 특정 Resource Cluster metadata가 손상된 것으로 확인

## 본 케이스에서는 Resource Cluster Group 2번에서 Resource Cluster 9번이 문제

# voma -m vmfs -f check -i verbose -a -Z xxx_07_voma_dump_new.file | less   Running VMFS Checker version 2.1 in check mode Initializing LVM metadata, Basic Checks will be done          DEBUG: LVM Magic at 1048576. Partition offset calculated to be 0        VERBOSE: Spanned Device table entry 0 is naa.60060e80072c500000302c5000001041:1          DEBUG: Verifying peBitmap (@offset 0x181000) and peTable (@offset 0x182000)        VERBOSE:  Index 0 PE Used 1 ID 0 poff 17825792 loff 0 len 3298266447872 version 1 is set in bitmap        VERBOSE:  Index 1 PE Used 0 ID 0 poff 0 loff 0 len 0 version 0 is not set in bitmap        VERBOSE:  Index 2 PE Used 0 ID 0 poff 0 loff 0 len 0 version 0 is not set in bitmap        VERBOSE:  Index 3 PE Used 0 ID 0 poff 0 loff 0 len 0 version 0 is not set in bitmap        VERBOSE:  Index 4 PE Used 0 ID 0 poff 0 loff 0 len 0 version 0 is not set in bitmap        VERBOSE:  Index 5 PE Used 0 ID 0 poff 0 loff 0 len 0 version 0 is not set in bitmap        VERBOSE:  Index 6 PE Used 0 ID 0 poff 0 loff 0 len 0 version 0 is not set in bitmap   <snip>          VERBOSE:  Index 8190 PE Used 0 ID 0 poff 0 loff 0 len 0 version 0 is not set in bitmap        VERBOSE:  Index 8191 PE Used 0 ID 0 poff 0 loff 0 len 0 version 0 is not set in bitmap        VERBOSE: numVolumes 1 numPEs 1 lastPEIndex 0 numPEMaps 0 extDevMetaOffset 0 consumedPEs 12287 totalBytes 3298533817856          DEBUG: Verifying volDesc table (@offset: 0x101000 size: 0x40000)        VERBOSE: First PE 0 last PE 12286 numPEs 12287 consumedPEs 1          trying to detect VMFS signatures        VERBOSE: Loading PE table @ disk offset 1581056 into memory Phase 1: Checking VMFS header and resource files    Detected VMFS-6 file system (labeled:'xxx_07') with UUID:5c980192-fba02734-13c6-54802851f0b6, Version 6:82          DEBUG: Expected numSubBlocks 16384, numPtrBlocks 0, numPb2Blocks 256, numFileDescs 16384, numJournalBlocks 16, numSFBs 3145216, numLFBs 6143          DEBUG: <FD c0 r6> FD type 0x5, flags 4          DEBUG: Checking FD <FD c0 r6> gen: 1,length 16908288 ,zla 1, numBlocks 17 tbzg 20     <snip>          VERBOSE: Check JBC cnum 8 (cg:2) offset 0x29020000 wi <gen 730142, mac 54802852dcd8, tod 1659487229>          DEBUG: Cluster 8 rcMeta flags 0 resMeta flags 0        VERBOSE: Checking JB cluster lock [type 10c00007 offset 688005120 v 513477, hb offset 3375104          gen 779739, mode 0, owner 00000000-00000000-0000-000000000000 mtime 29590821          num 0 gblnum 0 gblgen 0 gblbrk 0]        VERBOSE: Check JBC cnum 9 (cg:2) offset 0x29022000 wi <gen 0, mac 000000000000, tod 0> ### <-- !!  ON-DISK ERROR: Cluster number 11887 should be 9                                              ### <-- !!  ON-DISK ERROR: Invalid Resource Cluster version 24 should be 1                               ### <-- !!  ON-DISK ERROR: Invalid Resource Cluster signature 0 should be 1919118692                     ### <-- !!  ON-DISK ERROR: Invalid priority 646894212 cluster(9)                                         ### <-- !!  ON-DISK ERROR: Cluster 9 total resources 0 should be 8                                       ### <-- !!          DEBUG: Cluster 9 rcMeta flags 0 resMeta flags 0   <snip>          VERBOSE: Check JBC cnum 15 (cg:3) offset 0x2d02e000 wi <gen 730958, mac 54802852e66e, tod 1659487472>          DEBUG: Cluster 15 rcMeta flags 0 resMeta flags 0          Resource type: JBC, blks 257, (120/128) free resources, each of size 2097152, Organized as 4 CGs, 4 C/CG and 8 R/C, CGsize 67141632, 0th CG at 65536 Phase 2: Checking VMFS heartbeat region        VERBOSE: Checking HeartBeat [HB state abcdef01 offset 3145728 gen 0 stampUS 0 uuid 00000000-00000000-0000-000000000000 jrnl <FB 0> drv 0.0 lockImpl 0 ip ]        VERBOSE: Checking HeartBeat [HB state abcdef01 offset 3149824 gen 0 stampUS 0 uuid 00000000-00000000-0000-000000000000 jrnl <FB 0> drv 0.0 lockImpl 0 ip ]        VERBOSE: Checking HeartBeat [HB state abcdef01 offset 3153920 gen 0 stampUS 0 uuid 00000000-00000000-0000-000000000000 jrnl <FB 0> drv 0.0 lockImpl 0 ip ]   <snip>          VERBOSE: Checking HeartBeat [HB state abcdef01 offset 7323648 gen 0 stampUS 0 uuid 00000000-00000000-0000-000000000000 jrnl <FB 0> drv 0.0 lockImpl 0 ip ]        VERBOSE: Checking HeartBeat [HB state abcdef01 offset 7327744 gen 0 stampUS 0 uuid 00000000-00000000-0000-000000000000 jrnl <FB 0> drv 0.0 lockImpl 0 ip ]        VERBOSE: Checking HeartBeat [HB state abcdef01 offset 7331840 gen 0 stampUS 0 uuid 00000000-00000000-0000-000000000000 jrnl <FB 0> drv 0.0 lockImpl 0 ip ]        VERBOSE: Checking HeartBeat [HB state abcdef01 offset 7335936 gen 0 stampUS 0 uuid 00000000-00000000-0000-000000000000 jrnl <FB 0> drv 0.0 lockImpl 0 ip ] Phase 3: Checking all file descriptors.          DEBUG: Cluster 0 rcMeta flags 0 resMeta flags 4        VERBOSE: Checking FD lock [type 10c00001 offset 7471104 v 59, hb offset 3571712          gen 53, mode 0, owner 00000000-00000000-0000-000000000000 mtime 16091045          num 0 gblnum 0 gblgen 0 gblbrk 0]          DEBUG: Checking FD <FD c0 r0> gen: 1, length 73728, zla 1, numBlocks 1 tbzg 20 affinityFD <FD c0 r0> flags 0   <snip>            DEBUG: Cluster 61 rcMeta flags 0 resMeta flags 4          DEBUG: Cluster 62 rcMeta flags 0 resMeta flags 4          DEBUG: Cluster 63 rcMeta flags 0 resMeta flags 4 Phase 4: Checking pathname and connectivity.          DEBUG: Checking FD <FD c0 r0> gen: 1, length 73728, zla 1, numBlocks 1 tbzg 20 affinityFD <FD c0 r0> flags 0        VERBOSE: <FD c0 r0> : Skipping affinity check for fd        VERBOSE: addr SFB tbz 0 cow 0 cnum 0 rnum 8        VERBOSE: <FD c0 r0> TBZ 0 COW 0        VERBOSE: Push root directory <FD c0 r0> in queue          DEBUG: Checking directory <FD c0 r0> tE: 11          DEBUG: blktype 3 at offset 65536          DEBUG: blktype 1 at offset 69632   <snip>   Phase 5: Checking resource reference counts.          DEBUG: Recounting FD resources          DEBUG: Cluster 0 rcMeta flags 0 resMeta flags 4        VERBOSE: FD cnum 0, freeResources 247   <snip>            DEBUG: Recounting FB resources          DEBUG: Cluster 0 rcMeta flags 256 resMeta flags 42        VERBOSE: FB cnum 0, freeResources 0        VERBOSE: Cluster 0 total resources 512 free resources 0 in use 512          DEBUG: Cluster 0 affinityFD <FD c0 r0> inUseResources 1 largeThin FALSE (AFFSLOT)          DEBUG: Cluster 0 affinityFD <FD c0 r1> inUseResources 52 largeThin FALSE (AFFSLOT)          DEBUG: Cluster 0 affinityFD <FD c0 r2> inUseResources 129 largeThin FALSE (AFFSLOT)          DEBUG: Cluster 0 affinityFD <FD c0 r3> inUseResources 1 largeThin FALSE (AFFSLOT)          DEBUG: Cluster 0 affinityFD <FD c0 r4> inUseResources 320 largeThin FALSE (AFFSLOT)          DEBUG: Cluster 0 affinityFD <FD c0 r5> inUseResources 7 largeThin FALSE (AFFSLOT)          DEBUG: Cluster 0 affinityFD <FD c0 r6> inUseResources 2 largeThin FALSE (AFFSLOT)        VERBOSE: Cluster 0 totalResources 512 freeResources 0, After pass 1 - actualInUseResSlots 512 max overflow inUseRes 0        VERBOSE: Cluster 0 totalResources 512 freeResources 0 actualInUseResSlots 512 overflow reset 0        VERBOSE: Cluster 0 In use resource count match. Actual in use 512, sum of all inUseResources in slots 512        VERBOSE: Cluster 0 Overflow key reset to 0        VERBOSE: Cluster 0 affinityCount 8 Overflow afnty key inUseResources 0 (AFFCOUNT)          DEBUG: Cluster 1 rcMeta flags 256 resMeta flags 42        VERBOSE: FB cnum 1, freeResources 0   <snip>            DEBUG: Recounting JBC resources          DEBUG: Cluster 0 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 0, freeResources 8          DEBUG: Cluster 1 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 1, freeResources 8          DEBUG: Cluster 2 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 2, freeResources 8          DEBUG: Cluster 3 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 3, freeResources 8          DEBUG: Cluster 4 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 4, freeResources 8          DEBUG: Cluster 5 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 5, freeResources 8          DEBUG: Cluster 6 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 6, freeResources 8          DEBUG: Cluster 7 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 7, freeResources 8          DEBUG: Cluster 8 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 8, freeResources 8          DEBUG: Cluster 9 rcMeta flags 0 resMeta flags 0  ON-DISK ERROR: JBC inconsistency found: (9,0) allocated in bitmap, but never used  ON-DISK ERROR: JBC inconsistency found: (9,1) allocated in bitmap, but never used  ON-DISK ERROR: JBC inconsistency found: (9,2) allocated in bitmap, but never used  ON-DISK ERROR: JBC inconsistency found: (9,3) allocated in bitmap, but never used  ON-DISK ERROR: JBC inconsistency found: (9,4) allocated in bitmap, but never used  ON-DISK ERROR: JBC inconsistency found: (9,5) allocated in bitmap, but never used  ON-DISK ERROR: JBC inconsistency found: (9,6) allocated in bitmap, but never used  ON-DISK ERROR: JBC inconsistency found: (9,7) allocated in bitmap, but never used        VERBOSE: JBC cnum 9, freeResources 8          DEBUG: Cluster 10 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 10, freeResources 8          DEBUG: Cluster 11 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 11, freeResources 8          DEBUG: Cluster 12 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 12, freeResources 8          DEBUG: Cluster 13 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 13, freeResources 8          DEBUG: Cluster 14 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 14, freeResources 8          DEBUG: Cluster 15 rcMeta flags 0 resMeta flags 0        VERBOSE: JBC cnum 15, freeResources 8        VERBOSE: JBC: [type 6] Affinity Histogram:        VERBOSE:         affCnt 0       : 0        VERBOSE:         affCnt 1       : 0        VERBOSE:         affCnt 2       : 0        VERBOSE:         affCnt 3       : 0        VERBOSE:         affCnt 4       : 0        VERBOSE:         affCnt 5       : 0        VERBOSE:         affCnt 6       : 0        VERBOSE:         affCnt 7       : 0        VERBOSE:         affCnt 8  - 10 : 0        VERBOSE:         affCnt 11 - 15 : 0        VERBOSE:         affCnt 16 - 20 : 0        VERBOSE:         affCnt >20     : 0   Total Errors Found:           13          DEBUG: Closing devices

 

7. Deep Investigation of VOMA dump

## 동일한 VOMA Dump 파일에서 JBC로만 정렬하여 구분하니, 보다 명확하게 Cluster Group 2번의 Cluster 9번이 다름을 확인할 수 있음

## JBC Resource Cluster Group은 Index 기준으로 0~3까지 총 4개

## Resource Cluster Group 당 Resource Cluster는 Index 기준으로 0~3까지 총 4개

# voma -m vmfs -f check -i verbose -a -Z xxx_07_voma_dump_new.file | grep "Check JBC"        VERBOSE: Check JBC cnum 0 (cg:0) offset 0x21010000 wi <gen 733828, mac d06726bb892a, tod 1686553691> ### <-- !!        VERBOSE: Check JBC cnum 1 (cg:0) offset 0x21012000 wi <gen 732714, mac d06726bb8996, tod 1686456575>          VERBOSE: Check JBC cnum 2 (cg:0) offset 0x21014000 wi <gen 730770, mac 54802852e66e, tod 1659487420>        VERBOSE: Check JBC cnum 3 (cg:0) offset 0x21016000 wi <gen 729202, mac 54802851efde, tod 1659487289>              VERBOSE: Check JBC cnum 4 (cg:1) offset 0x25018000 wi <gen 732340, mac 54802852dcd8, tod 1659487455>        VERBOSE: Check JBC cnum 5 (cg:1) offset 0x2501a000 wi <gen 730272, mac 54802851f0b6, tod 1659487389>        VERBOSE: Check JBC cnum 6 (cg:1) offset 0x2501c000 wi <gen 832506, mac d06726bb88ac, tod 1686553390>        VERBOSE: Check JBC cnum 7 (cg:1) offset 0x2501e000 wi <gen 833490, mac d06726bb6200, tod 1686552729>          VERBOSE: Check JBC cnum 8 (cg:2) offset 0x29020000 wi <gen 73        VERBOSE: Check JBC cnum 9 (cg:2) offset 0x29022000 wi <gen 0, mac 000000000000, tod 0>                ### <-- !!        VERBOSE: Check JBC cnum 10 (cg:2) offset 0x29024000 wi <gen 1367232, mac d06726bb6332, tod 1686553689>        VERBOSE: Check JBC cnum 11 (cg:2) offset 0x29026000 wi <gen 846830, mac d06726bb8c66, tod 1686553751>          VERBOSE: Check JBC cnum 12 (cg:3) offset 0x2d028000 wi <gen 732578, mac d06726bb6332, tod 1675140716>        VERBOSE: Check JBC cnum 13 (cg:3) offset 0x2d02a000 wi <gen 832906, mac d06726bb6e96, tod 1686553030>        VERBOSE: Check JBC cnum 14 (cg:3) offset 0x2d02c000 wi <gen 730652, mac d06726bb8bc4, tod 1686552789>        VERBOSE: Check JBC cnum 15 (cg:3) offset 0x2d02e000 wi <gen 730958, mac 54802852e66e, tod 1659487472>

 

8. Hexdump 수집

# dd if=/vmfs/devices/disks/naa.60060e80072c500000302c5000001041 of=/vmfs/volumes/<여유있는 datastore>/naa.60060e80072c500000302c5000001041.bin bs=1M count=1500 # dd if=/vmfs/devices/disks/naa.60060e80072c500000302c5000001045 of=/vmfs/volumes/<여유있는 datastore>/naa.60060e80072c500000302c5000001045.bin bs=1M count=1500

 

9. Investigation of Hexdump

## VOMA Dump 결과에서 확인되는 offset을 이용하여, 해당 위치의 데이터 확인 시도

## 예를 들어, 첫 번째 JBC Cluster인 offset 0x2101000을 가봤으나, metadata 같이 보이지 않음

## 이에 대한 정보가 부족한 관계로 최초에는 아래 링크에 있는 Resource File별 Signature를 이용하여 시도

Reverse Engineering Virtual Machine File System 6 (VMFS 6) | SANS Institute

## 0x10C00007 값을 Little Endian으로 하여 검색 시도 시, 0x2101000이 아닌 위치에 존재

## 확인 결과, 0x2101000 Offset 값은 VMFS의 Logical Layout 상에서의 Offset이기 때문에 Hexdump에서 올바른 위치를 찾으려면 Logical Layout 대신 LVM의 Physical Layout 주소를 이용해야 함

## Code 상으로는 다음과 같이, Physical Layout과 Logical Layout 간에는 17MB 차이를 알 수 있음

* X = ALIGN_UP(17MB, FS_block_size) if volume was upgraded from VMFS-2

* = 17MB otherwise

## 따라서 VOMA Dump 상에서 확인되는 0x2101000 Offset은 Logical Layout에서의 Offset이므로 여기서 17MB인 0x1100000을 더하면, Physical Layout의 Offset을 획득할 수 있음

## 아래 예제에서 hexdump에서 사용하는 옵션 중 -s 705822720은 10진수로 이를 16진수로 변환하면, 0x2a120000

## 이 값은 문제가 발생한 Resource Cluster 9번 이전의 8번의 Logical Layout Offset인 0x29020000에 17MB인 0x1100000을 더한 값

## 0x29020000 + 0x1100000 = 0x2a120000

## Resource Cluster 9번의 경우 다른 Resource Cluster와 달리, Resource Cluster Metadata의 시작 위치에서 +0x10 만큼 위치에 Signature인 64 6d 63 72가 위치하지 않고,

## Resource Cluster Metadata의 시작 위치에 01 ef cd ab 값이 기록되어 있음

## 이 값은 Little Endian이므로 0xabcdef01로 보면 이는 ENUM Type으로 정의되어 있는 Heartbeat State 종류 중, HB_CLEAR로 확인

## 즉, 해당 Resource Cluster는 원래 JBC로 사용되어야 하는데 HB Slot으로 잘못 이용된 것으로 확인

VERBOSE: Check JBC cnum 8 (cg:2) offset 0x29020000 wi <gen 73 VERBOSE: Check JBC cnum 9 (cg:2) offset 0x29022000 wi <gen 0, mac 000000000000, tod 0> VERBOSE: Check JBC cnum 10 (cg:2) offset 0x29024000 wi <gen 1367232, mac d06726bb6332, tod 1686553689>   jhaewon@gss-prd-csp-4:vmfs$ hexdump -s 705822720 -n 16384 -C xxx_07_voma_dump_new.file 2a120000  07 00 c0 10 00 00 02 29  00 00 00 00 00 00 3f 00  |.......)......?.| ### <-- !! 2a120010  00 00 00 00 fd b4 02 00  00 00 00 00 3d 48 16 00  |............=H..| 2a120020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 2a120030  00 00 00 00 00 00 00 00  36 96 84 00 00 00 00 00  |........6.......| 2a120040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| * 2a121010  64 6d 63 72 00 00 00 00  08 00 00 00 00 00 00 00  |dmcr............| ### <-- !! +0x1010 2a121020  08 00 08 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 2a121030  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 2a121040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 2a121050  00 00 00 00 00 00 00 00  1e 24 0b 00 54 80 28 52  |.........$..T.(R| 2a121060  dc d8 fd c3 e9 62 00 00  00 00 00 00 00 00 00 00  |.....b..........| 2a121070  00 00 00 00 00 00 00 00  00 00 00 00 02 00 00 00  |................| 2a121080  ff 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 2a121090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| * 2a122000  07 00 c0 10 00 20 02 29  00 00 00 00 00 80 33 00  |..... .)......3.| ### <-- !! 2a122010  00 00 00 00 db e5 0b 00  00 00 00 00 c5 d5 07 00  |................| 2a122020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 2a122030  00 00 00 00 00 00 00 00  25 85 c3 01 00 00 00 00  |........%.......| 2a122040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| * 2a123000  01 ef cd ab 00 80 33 00  00 00 00 00 40 6d 09 00  |......3.....@m..| ### <-- !!   2a123010  00 00 00 00 84 d2 8e 26  6f 2e 00 00 00 00 00 00  |.......&o.......| ### <-- !! +0x1010 2a123020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 2a123030  18 00 00 00 52 04 31 30  2e 31 39 37 2e 32 31 37  |....R.10.197.217| 2a123040  2e 33 37 00 00 00 00 00  00 00 00 00 00 00 00 00  |.37.............| 2a123050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| * 2a124000

 

위에서 설명했던 Logical Layout과 Physical Layout 개념도

 

[해결 방안]

1. voma의 advanced fix 옵션을 이용한 corruption된 부분 조치 시도 가능

2. 고객사의 경우에는 이미 문제가 발생한 Datastore에서 VM들을 Storage Migration한 상태이므로 해당 Datastore를 Re-format 해서 조치 가능

## 다만, 문제가 이미 발생한 Datastore에서 Storage Migration은 굉장히 위험한 선택일 수 있음

## 이미 손상된 부분이 실제 VM이 사용하는 파일들인 경우에 Storage Migration 후에 VM이 Running 상태로 전환되지 못할 수 있음

## 따라서, 가장 안전한 방법은 다른 Datastore에 문제가 발생한 Datastore에 위치한 VM들을 Retore 하는 것

 

[Next Plan]

문제 원인을 파악하기 위해서 문제가 재현되는 환경이 중요

문제가 재현되는 환경이 있다면, VMFS Metadata Tracing 설정을 한 후, 재현 시점의 데이터 확인 필요

그 후에 VMFS에 대한 Debug Patch 작성하여, 고객사 환경에 적용을 하는 단계로 진행될 수도 있음