Re: need help how to debug xfs crash issue xfs_iunlink_remove: xfs_inotobp() returned error 22

[符永涛 <yongtaofu@xxxxxxxxx>]

[/mnt/xfsd/lost+found]# pwd
/mnt/xfsd/lost+found
[ /mnt/xfsd/lost+found]# ls -l
total 0
-rw-r--r-- 1 root root 0 Feb  1 19:18 6235944
[ /mnt/xfsd/lost+found]# sudo getfattr -m . -d -e hex 6235944
[ /mnt/xfsd/lost+found]#

2013/4/10 符永涛 <yongtaofu@xxxxxxxxx>

Here's the file info in lost+found:

[ lost+found]# pwd
/mnt/xfsd/lost+found
[ lost+found]# ls -l
总用量 4
---------T 1 root root 0 2月  28 15:42 3097
---------T 1 root root 0 2月  28 15:16 6169
[root@xxxxxxxxxxxx lost+found]# sudo getfattr -m . -d -e hex 6169
[root@xxxxxxxxxxxx lost+found]# sudo getfattr -m . -d -e hex 3097
# file: 3097
trusted.afr.ec-data-client-2=0x000000000000000000000000
trusted.afr.ec-data-client-3=0x000000000000000000000000
trusted.afr.ec-data1-client-2=0x000000000000000000000000
trusted.afr.ec-data1-client-3=0x000000000000000000000000
trusted.gfid=0x2bb701d327c44bb0af78d69e89f192a4
trusted.glusterfs.dht.linkto=0x65632d64617461312d7265706c69636174652d3400
trusted.glusterfs.quota.b8e8b3ef-0268-40af-93b6-257c4c7ef17a.contri=0x0000000004249000

It seems they're some link files for glusterfs dht xlator.

Thank you.

2013/4/10 Eric Sandeen <sandeen@xxxxxxxxxxx>

On 4/9/13 10:18 AM, 符永涛 wrote:

> The servers are back to service now and It's hard to run xfs_repair. It always happen bellow is the xfs_repair log when it happens on another server several days ago.

...

> 第二步
> repair的log
>
> sh-4.1$ sudo xfs_repair /dev/glustervg/glusterlv
> Phase 1 - find and verify superblock…
> Phase 2 - using internal log
>         - zero log…
>         - scan filesystem freespace and inode maps…
> agi unlinked bucket 0 is 4046848 in ag 0 (inode=4046848)
> agi unlinked bucket 5 is 2340485 in ag 0 (inode=2340485)
> agi unlinked bucket 6 is 2326854 in ag 0 (inode=2326854)
> agi unlinked bucket 8 is 1802120 in ag 0 (inode=1802120)
> agi unlinked bucket 14 is 495566 in ag 0 (inode=495566)
> agi unlinked bucket 16 is 5899536 in ag 0 (inode=5899536)
> agi unlinked bucket 19 is 4008211 in ag 0 (inode=4008211)
> agi unlinked bucket 21 is 4906965 in ag 0 (inode=4906965)
> agi unlinked bucket 23 is 2022231 in ag 0 (inode=2022231)
> agi unlinked bucket 24 is 1626200 in ag 0 (inode=1626200)
> agi unlinked bucket 25 is 938585 in ag 0 (inode=938585)
> agi unlinked bucket 30 is 4226526 in ag 0 (inode=4226526)
> agi unlinked bucket 34 is 4108962 in ag 0 (inode=4108962)
> agi unlinked bucket 37 is 1740389 in ag 0 (inode=1740389)
> agi unlinked bucket 39 is 247399 in ag 0 (inode=247399)
> agi unlinked bucket 40 is 6237864 in ag 0 (inode=6237864)
> agi unlinked bucket 43 is 3404331 in ag 0 (inode=3404331)
> agi unlinked bucket 45 is 2092717 in ag 0 (inode=2092717)
> agi unlinked bucket 48 is 4041008 in ag 0 (inode=4041008)
> agi unlinked bucket 50 is 1459762 in ag 0 (inode=1459762)
> agi unlinked bucket 56 is 852024 in ag 0 (inode=852024)

If this machine is still around in similar state, can you do a

# find /path/to/mount -inum $INODE_NUMBER

for the inode numbers above, and see what files they are?
That might give us a clue about what operations were happening
to them.  Dumping the gluster xattrs on those files
might also be interesting.  Just guesses here, but it'd be a
little more data.

(if this is an old repair, maybe doing the same for your most
recent incident would be best)

Thanks,
-Eric

>         - found root in ode chunk
> Phase 3 - for each AG…
>         - scan and clear agi unlinked lists…
>         - process known inodes and perform inode discovery…
>         - agno = 0
> 7f8220be6700: Badness in key lookup (length)
> bp=(bno 123696, len 16384 bytes) key=(bno 123696, len 8192 bytes)

(FWIW the above warnings look like an xfs_repair bug, not related)

-Eric

--
符永涛

--
符永涛