Hi All, We have encountered a case that extent alloc gd has been abnormally cleared. In our environment, the volume has been formatted with 128 slots but actually has 64 slots in use. Since extent alloc is allocated when formatting, and extent_alloc:0107 (inode 259) hasn't been use in our environment, I have no idea how it can happen. Does any one have an idea? The fsck log is attached below: fsck.ocfs2 1.6.4 Checking OCFS2 filesystem in /dev/disk/by-id/scsi-360022a11000b17590551993300000001: Label: <NONE> UUID: 908A3228F49B41468FFC4927FAE1E54F Number of blocks: 2415918080 Block size: 4096 Number of clusters: 301989760 Cluster size: 32768 Number of slots: 128 /dev/disk/by-id/scsi-360022a11000b17590551993300000001 was run with -f, check forced. Pass 0a: Checking cluster allocation chains Pass 0b: Checking inode allocation chains Pass 0c: Checking extent block allocation chains [CHAIN_LINK_MAGIC] Chain 24 in allocator at inode 259 contains a reference at depth 0 to block 6578184 which doesn't have a valid checksum. Truncate this chain? y [CHAIN_BITS] Chain 24 in allocator inode 259 has 1023 bits marked free out of 1024 total bits but the block groups in the chain have 0 free out of 0 total. Fix this by updating the chain record? y [CHAIN_EMPTY] Chain 24 in allocator inode 259 is empty. Remove it from the chain record array in the inode and shift further chains into its place? y [GROUP_CHAIN] Group descriptor at block 6603784 was found in chain 24 but it claims to be in chain 49. Update the descriptor's recorded chain? y Duplicate clusters detected. Pass 1b will be run Pass 1: Checking inodes and blocks. ...... Running additional passes to resolve clusters claimed by more than one inode... Pass 1b: Determining ownership of multiply-claimed clusters pass1b: Inode type does not contain extents while processing inode 17