xfs_iunlink_remove: xfs_inotobp() returned error 22 -- debugging

[符永涛]

After change mount option to sync shutdown still happens, and I got a trace
again, the inode 0x1c57d is abnormal.
https://docs.google.com/file/d/0B7n2C4T5tfNCYW1jNWhBbXBYakE/edit?usp=sharing
I have a question if the problem is hard to reproduce why I got 8 times in
a week only in a test cluster with 8 node?
What's the problem?


2013/4/20 符永涛 <yongtaofu at gmail.com>

> Dear xfs experts,
> Does mount with sync option helps to isolate this problem?
>
>
> 2013/4/20 符永涛 <yongtaofu at gmail.com>
>
>> Dear Eric and xfs experts,
>> Updated progress is after more than one day glusterfs rebalance 3 of our
>> servers xfs shutdown(8 servers in the test cluster). The errors are
>> identical. Actually one of the most serious accident for us is 8 of our
>> servers xfs shutdown at the same time during glusterfs rebalance.
>> Thank you very much!
>>
>>
>> 2013/4/20 符永涛 <yongtaofu at gmail.com>
>>
>>> Dear Eric,
>>> I noticed some functions call the xfs_lock_two_inodes(dp, ip,
>>> XFS_ILOCK_EXCL); twince but not in xfs_remove.
>>>
>>>
>>> 2013/4/20 符永涛 <yongtaofu at gmail.com>
>>>
>>>> There it is, I use latest 279.19.1 and only apply xfs trace path.
>>>>
>>>>
>>>> 2013/4/20 Eric Sandeen <sandeen at sandeen.net>
>>>>
>>>>> On 4/19/13 10:00 AM, 符永涛 wrote:
>>>>> > Dear Eric,
>>>>> >
>>>>> > I checked rh srpm
>>>>> https://content-web.rhn.redhat.com/rhn/public/NULL/kernel/2.6.32-279.19.1.el6/SRPMS/kernel-2.6.32-279.19.1.el6.src.rpm?__gda__=1366390847_8550b8568c50ea46b3180266b476353d&ext=.rpm
>>>>> > And the code is same, as following:
>>>>> >
>>>>> > __rwsem_do_wake(struct rw_semaphore *sem, int wakewrite)
>>>>> > {
>>>>>
>>>>> need to look in lib/rwsem.c not lib/rwsem-spinlock.c
>>>>>
>>>>> Thanks,
>>>>> -Eric
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 符永涛
>>>>
>>>
>>>
>>>
>>> --
>>> 符永涛
>>>
>>
>>
>>
>> --
>> 符永涛
>>
>
>
>
> --
> 符永涛
>



-- 
符永涛
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20130420/6a085421/attachment.html>