Hi,
I ran the XFS QA stuff from CVS on kernel-smp-2.4.22-1.2129.nptl.xfs.
(which is derived from the kernel-2.4.22-1.2115.nptl.xfs in the
testing/FC1 directory on oss.sgi.com). I ran the tests on a different
machine from the one I originally had problems on since I don't have
any spare partitions to try this on. It passed 013 but failed on 018,
019, 064, 073 and 076. Some of these failures seem to be just minor
differences in output. 073 and 076, however, hung. Let me know if
you'd like to look at the *.bad files.
I tried building a kernel from yesterday's linux-2.4 CVS and the QA
tests failed on the 018, 019, 064 and 073 but none hung.
One key bit of information I see I have not mentioned is this is on
RHEL3 ES using the default gcc 3.2.3. I noticed someone reporting
a problem with XFS and LVM when using gcc 3.2.3.
THe original problem also happened under RedHat 8.0 with the kernel
compiled with the default gcc 3.2 so this may have nothing to do with
the orignal problem.
I'd appreciate any suggestions on what to try next. Would you suggest
running the linux-24-xfs from CVS on a "production" machine with 5.6 TB
of disk on it?
Nathan Straz wrote:
On Mon, Dec 15, 2003 at 09:05:16AM -0600, jansen wrote:
I did an "strace" on xfsdump and these ioctl commands are the ones that
appear to make the high load average:
14054 ioctl(4, 0xc0105865, 0xbffff530) = 0
14054 ioctl(4, 0xc0105865, 0xbffff530) = 0
14054 ioctl(4, 0xc0105865, 0xbffff530) = 0
14054 ioctl(4, 0xc0105865, 0xbffff530) = 0
14054 ioctl(4, 0xc0105865, 0xbffff530) = 0
14054 ioctl(4, 0xc0105865, 0xbffff530) = 0
Looks like it's stuck in a loop doing XFS_IOC_FSBULKSTAT. I think I'm
hitting something similar. In my case I'm running on ia64 and the
system becomes totally unresponsive. Luckily I have KDB. :)
Can you run some of the XFS QA suite from CVS? 013 in particular has
been exposing this to me. Run it on a scratch partition.
--
------- Stephan
|