xfs
[Top] [All Lists]

Re: [PATCH] repair: fix wrong logic when validating node magic number

To: Eryu Guan <eguan@xxxxxxxxxx>
Subject: Re: [PATCH] repair: fix wrong logic when validating node magic number
From: Zorro Lang <zorro.lang@xxxxxxxxx>
Date: Thu, 27 Aug 2015 11:35:20 +0800
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=13CUdXM6mDchEsb8ZPzsUxmJoWDXOYu0L/G5ZdrcUZs=; b=buTJfFW+TsoUsHOk62iHGk5DRPqI1KjMTFl/YvrbJ7Ydt1LjmvkLkEVaAB0bQgeUOs NWlkff5zL0c/popIXZiA60gsXYmyjS70ILH8taIiq7Xu8P5IHaGPJS3Mt+CbW17kiklA K5srCAjuSltBCvXEgzT7XSM8A8Zpo+FDP64bC+D5ZvDLRC/xotOj+MrqAvvPmybBokeM FIaLSVx0e6cE0Ql01QE/auHKKys8Xd9Fhey2rcEG5WqBvSryupUOQVCoftpg26c/x/TB rrgUDVlxr4ZP02cO7fgIQmaBR4hcsMS9OV6ZxsTfNivne2fxWmHPv3X01/VBUE0UWgY+ TKew==
In-reply-to: <20150813071524.GI17933@xxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <1439449276-1699-1-git-send-email-eguan@xxxxxxxxxx> <20150813071524.GI17933@xxxxxxxxxxxxxxxxxxxxxxxxxx>
2015-08-13 15:15 GMT+08:00 Eryu Guan <eguan@xxxxxxxxxx>:
> On Thu, Aug 13, 2015 at 03:01:16PM +0800, Eryu Guan wrote:
>> Magic number is wrong only when != XFS_DA_NODE_MAGIC and
>> != XFS_DA3_NODE_MAGIC.
>>
>> This is triggered by shared/002 when testing 512 block size XFS.
>>
>>   Phase 1 - find and verify superblock...
>>   Phase 2 - using internal log
>>           - scan filesystem freespace and inode maps...
>>           - found root inode chunk
>>   Phase 3 - for each AG...
>>           - scan (but don't clear) agi unlinked lists...
>>           - process known inodes and perform inode discovery...
>>           - agno = 0
>>   bad magic number febe in block 64 (108) for directory inode 35
>>   ......
>>
>> Fix it by changing "||" to "&&".
>>
>> Signed-off-by: Eryu Guan <eguan@xxxxxxxxxx>
>
> With this patch applied, shared/002 still fails on 512 block size XFS,


This failure not only be reproduced on 512 block size XFS. When I increase
the stress of shared/002, this bug can be reproduced on any block size XFS.

For example, on my test machine, when I increase $num_attrs to 6000, this
bug be reproduced on 1k block size xfs. When increased $num_attrs to 80k,
this bug be reproduced on 4k block size xfs.

So this's not a block size related bug.

BTW, xfs_repair can repair this corruption. And from shared/002 output, we can
see shared/002 use getfattr to sure all xattrs haven been wrote in
device correctly.
So this corruption maybe due to xfs log problems.

Thanks,
Zorro Lang

> full xfs_repair -n output is
>
> *** xfs_repair -n output ***
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
>         - scan filesystem freespace and inode maps...
>         - found root inode chunk
> Phase 3 - for each AG...
>         - scan (but don't clear) agi unlinked lists...
>         - process known inodes and perform inode discovery...
>         - agno = 0
> problem with attribute contents in inode 35
> would clear attr fork
> bad nblocks 67 for inode 35, would reset to 0
> bad anextents 5 for inode 35, would reset to 0
>         - agno = 1
>         - agno = 2
>         - agno = 3
>         - process newly discovered inodes...
> Phase 4 - check for duplicate blocks...
>         - setting up duplicate extent list...
>         - check for inodes claiming duplicate blocks...
>         - agno = 0
>         - agno = 1
>         - agno = 2
>         - agno = 3
> No modify flag set, skipping phase 5
> Phase 6 - check inode connectivity...
>         - traversing filesystem ...
>         - traversal finished ...
>         - moving disconnected inodes to lost+found ...
> Phase 7 - verify link counts...
> No modify flag set, skipping filesystem flush and exiting.
> *** end xfs_repair output
>
> And a simplified reproducer is just adding >= 577 xattrs to file foo on
> 512 block size XFS, no dmflaky is needed.
>
> num_xattrs=577
> for ((i = 1; i <= $num_xattrs; i++)); do
>         name="user.attr_$(printf "%04d" $i)"
>         $SETFATTR_PROG -n $name -v "val_$(printf "%04d" $i)" $SCRATCH_MNT/foo
> done
>
> And it's easily reproduced.
>
> Thanks,
> Eryu
>
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs

<Prev in Thread] Current Thread [Next in Thread>