Re: 2.6.30 panic - xfs_fs_destroy_inode

[Lachlan McIlroy <lmcilroy@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4585 bytes --]

It looks to me like xfs_reclaim_inode() has returned EAGAIN because the
XFS_RECLAIM flag was set on the xfs inode.  This implies we are trying
to reclaim an inode that is already in the process of being reclaimed.
I'm not sure how this happened but it could be a simple case of ignoring
this error since the reclaim is already in progress.

----- "Patrick Schreurs" <patrick@news-service.com> wrote:

> 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@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@oss.sgi.com
> >>>> http://oss.sgi.com/mailman/listinfo/xfs
> >>> <sb06-20090619.png>
> >>
> >> _______________________________________________
> >> xfs mailing list
> >> xfs@oss.sgi.com
> >> http://oss.sgi.com/mailman/listinfo/xfs
> > 
> > _______________________________________________
> > xfs mailing list
> > xfs@oss.sgi.com
> > http://oss.sgi.com/mailman/listinfo/xfs
> 
> 
> [image/jpeg:sb08-20090623.jpg]
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

[-- Attachment #2: sb08-20090623.jpg --]
[-- Type: image/jpeg, Size: 70970 bytes --]

[-- Attachment #3: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs