[Ocfs2-tools-devel] A patch for fsck.ocfs2 of ocfs2-tools: verify_chain_alloc.patch

[tao.ma]

When the last chain rec is copied to another position,
it should be cleaned up. Or In some case it will
be reused and cause the error.

Here is the wrong situation I meet when I implement fswreck of ocfs2-tools.
I have a 10G /dev/sdb1, and formatted to ocfs2.
mkfs.ocfs2 -b 1K -C 4K -N 4 /dev/sdb1 
1. After formatting, the last chain record looks like this:
Group Chain: 50   Parent Inode: 15  Generation: 172491420
        ##   Block#            Total    Used     Free     Contig   Size
        0    1536000           7680     1        7679     7679     960
        1    3102720           7680     1        7679     7679     960
        2    4669440           7680     1        7679     7679     960
        3    6236160           7680     1        7679     7679     960
        4    7802880           7680     1        7679     7679     960
        5    9369600           7680     1        7679     7679     960
2. For some reason, the chain 0 is corrupted to empty(cl_recs[0].c_blkno=0).
3. run fsck.ocfs2 -f /dev/sdb1. The last chain will move to chain 0, and 
the original group in chain 0 will also be added here. now the 
cl_next_free_rec=50, and cl_recs[50].c_blkno=1536000
Group Chain: 0   Parent Inode: 15  Generation: 172491420
        ##   Block#            Total    Used     Free     Contig   Size
        0    9400320           7680     1        7679     7679     960
        1    7833600           7680     1        7679     7679     960
        2    6266880           7680     1        7679     7679     960
        3    4700160           7680     1        7679     7679     960
        4    3133440           7680     1        7679     7679     960
        5    1566720           7680     1        7679     7679     960
        6    4                 7680     7680     0        0        960
        7    1536000           7680     1        7679     7679     960
        8    3102720           7680     1        7679     7679     960
        9    4669440           7680     1        7679     7679     960
        10   6236160           7680     1        7679     7679     960
        11   7802880           7680     1        7679     7679     960
        12   9369600           7680     1        7679     7679     960
4. For some reason, the block 9400320 is corrupted again. and now
bg->bg_next_group point to some very large blocks which exceed the 
volume's size.
5. run fsck.ocfs2 -f /dev/sdb1. The result is as follows.
1)CHAIN_LINK_RANGE will be found, and the chain 0 is truncated.
2) The lost group desc will be found and added to chain one by one 
during the process of GROUP_EXPECTED_DESC.
for group 1536000, it will be found, added to chain 50 first and linked 
to itself.

So the interesting thing happens:
Group Chain: 50   Parent Inode: 15  Generation: 177938607
        ##   Block#            Total    Used     Free     Contig   Size
        0    9369600           7680     1        7679     7679     960
        1    7802880           7680     1        7679     7679     960
        2    6236160           7680     1        7679     7679     960
        3    4669440           7680     1        7679     7679     960
        4    3102720           7680     1        7679     7679     960
        5    1536000           7680     1        7679     7679     960
        6    1536000           7680     1        7679     7679     960
        7    1536000           7680     1        7679     7679     960
        8    1536000           7680     1        7679     7679     960
        9    1536000           7680     1        7679     7679     960
        10   1536000           7680     1        7679     7679     960
        11   1536000           7680     1        7679     7679     960
        12   1536000           7680     1        7679     7679     960
It never ends.





-- 
* **     Tao Ma
*     Member of Techincal Staff *

Oracle Asia Development Center
Emerging Technology & Solution Development
*
Tel:        +86 10 8278 6026
URL:       OADC Intranet <http://cdc.oraclecorp.com/>, Oracle.com/cdc 
<http://www.oracle.com/cdc/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: verify_chain_alloc.patch
Type: text/x-patch
Size: 648 bytes
Desc: not available
Url : http://oss.oracle.com/pipermail/ocfs2-tools-devel/attachments/20060920/d650382a/verify_chain_alloc.bin