2.6.30 panic - xfs_fs_destroy_inode

[Patrick Schreurs]

Another one (see attachement). This time on a server with SAS drives and 
without the lazy-count option:

meta-data=/dev/sdb               isize=256    agcount=4, agsize=27471812 
blks
          =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=109887246, imaxpct=25
          =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=32768, version=2
          =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0

We really don't want to rollback to 2.6.28.x as this doesn't solve the 
issue.

Any hint would be appreciated.

-Patrick

Patrick Schreurs wrote:
> Just had another one. It's likely we'll have to downgrade to 2.6.28.x.
> 
> These servers have 28 SCSI disks mounted separately (JBOD). The workload 
> is basically i/o load (90% read, 10% write) from these disks. The 
> servers are not extreme busy (overloaded).
> 
> xfs_info from a random disk:
> 
> sb02:~# xfs_info /dev/sdb
> meta-data=/dev/sdb               isize=256    agcount=4, agsize=18310547 
> blks
>          =                       sectsz=512   attr=2
> data     =                       bsize=4096   blocks=73242187, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0
> log      =internal               bsize=4096   blocks=32768, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> As you can see we use lazy-count=1. Mount options aren't very exotic: 
> rw,noatime,nodiratime
> 
> We are seeing these panic's on at least 3 different servers.
> 
> If you have any hints on how to investigate, we would greatly appreciate 
> it.
> 
> -Patrick
> 
> Eric Sandeen wrote:
>> Others aren't hitting this, what sort of workload are you running when 
>> you hit it?
>>
>> I have not had time to look at it yet but some sort of testcase may 
>> greatly help.
>>
>> -Eric
>>
>> On Jun 20, 2009, at 5:18 AM, Patrick Schreurs 
>> <patrick at news-service.com> wrote:
>>
>>> Unfortunately another panic. See attachment.
>>>
>>> Would love to receive some advice on this issue.
>>>
>>> Thanks in advance.
>>>
>>> -Patrick
>>>
>>> Patrick Schreurs wrote:
>>>> Eric Sandeen wrote:
>>>>> Patrick Schreurs wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> We are experiencing kernel panics on servers running 2.6.29(.1) 
>>>>>> and 2.6.30. I've included two attachments to demonstrate.
>>>>>>
>>>>>> The error is:
>>>>>> Kernel panic - not syncing: xfs_fs_destroy_inode: cannot reclaim ...
>>>>>>
>>>>>> OS is 64bit Debian lenny.
>>>>>>
>>>>>> Is this a known issue? Any comments on this?
>>>>>
>>>>> It's not known to me, was this a recent upgrade?  (IOW, did it start
>>>>> with .29(.1)?
>>>> We've seen this on 2 separate servers. It probably happened more 
>>>> often, but we didn't captured the panic message. One server was 
>>>> running 2.6.29.1, the other server was running 2.6.30. Currently 
>>>> we've updated all similar servers to 2.6.30.
>>>> If we can provide you with more details to help fix this issue, 
>>>> please let us know.
>>>> -Patrick
>>>> _______________________________________________
>>>> xfs mailing list
>>>> xfs at oss.sgi.com
>>>> http://oss.sgi.com/mailman/listinfo/xfs
>>> <sb06-20090619.png>
>>
>> _______________________________________________
>> xfs mailing list
>> xfs at oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs
> 
> _______________________________________________
> xfs mailing list
> xfs at oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sb08-20090623.jpg
Type: image/jpeg
Size: 70970 bytes
Desc: not available
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20090623/dddd4a96/attachment.jpg>