http://oss.sgi.com/bugzilla/show_bug.cgi?id=898
Summary: Kernel panic - not syncing: xfs_fs_destroy_inode:
cannot reclaim 0xffff88023410e980
Product: XFS
Version: Current
Platform: PC
OS/Version: Linux
Status: NEW
Severity: critical
Priority: P5
Component: XFS kernel code
AssignedTo: xfs-masters@xxxxxxxxxxx
ReportedBy: russell@xxxxxxxxxxxxxx
Estimated Hours: 0.0
Classification: Unclassified
I have built a pretty big machine that culminates in a 92 TB XFS file system
that we seem to be having problems with.
As you see in the summary, we are getting apparently random kernal panics, but
always with a message of: xfs_fs_destroy_inode: cannot reclaim
0xXXXXXXXXXXXXXXXXX.
OS/Kernel details:
root@saturn:~# uname -a
Linux saturn 2.6.32-21-server #32-Ubuntu SMP Fri Apr 16 09:17:34 UTC 2010
x86_64 GNU/Linux
The (relevant) hardware is 2x Areca 1680 with 24x 2Tb SAS disk on each, in a
raid 5 configuration, giving 2x 46TB block devices. These are then made into a
raid 0 stripe with mdadm to bind the two together into the single 92Tb store.
parted output:
root@saturn:~# parted /dev/md0 print
Model: Unknown (unknown)
Disk /dev/md0: 92.0TB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 262kB 92.0TB 92.0TB xfs shared
Judging by the lack of google results that turn up when I search for
"xfs_fs_destroy_inode: cannot reclaim", this seems to be a very rare kind of
crash, and yet we've had it happen twice in the past 10 days. That said, I did
find a useful email chain in the sgi xfs mailing list archives indicating a
possible race condition, however that was talking about an older kernel.
Can some one please guide me as to what to do/try now? Are there any possible
tuning parameters I can use at mount time? Is there any debugging/extra
information I can provide to help resolve this?
Many thanks in advance.
--
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
|