[Top] [All Lists]

Re: xfsdump

To: William Moss <bill.m.moss@xxxxxxxxx>
Subject: Re: xfsdump
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Sun, 18 Dec 2011 19:50:30 -0600
Cc: xfs@xxxxxxxxxxx
In-reply-to: <CAEt9JqzmcRT2g6z1k3t5eFM7e1rvrrHQRf_enpvJx+HXgwOERA@xxxxxxxxxxxxxx>
References: <CAEt9JqzmcRT2g6z1k3t5eFM7e1rvrrHQRf_enpvJx+HXgwOERA@xxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
On 12/17/11 11:22 AM, William Moss wrote:
> Since approx. kernel 2.6.35 (kernel.org <http://kernel.org>) I have
> been having a problem with xfsdump(8) with my custom compiled kernels
> but not with the one that comes with openSUSE. During a differential
> dump (1..9) it will lock up, become a kernel stuck process that
> cannot be killed, while determining the files that need to be dumped.
> This has not occurred with dump level zero nor with the kernel as
> supplied from openSUSE. I have played with the kernel options that
> seem relevant to xfs (a find for xfs as well as ACPI, etc.) and
> nothing seems to effect the problem. Other than this, everything
> works fine and the kernel has better performance and support in the
> areas that I compile it for with respect to my hardware. I was hoping
> that you could inform me as to what options for the kernel might
> cause this problem. Note that a reboot or even an 'init 0 --- init 3'
> will clear the problem for at least one more differential dump.
> openSUSE: 11.4 CPU : AMD 64 AM2 socket RAM: 4GB DDR2 Drives: SATA/3
> Boot is a 650GB WD, /usr/local is a 1.5TB WD
> Kernel: 3.1.4 I compile the kernel with the AMD64 optimization turned
> on.

If the kernel thread is really stuck, sysrq-D (or echo d > /proc/sysrq-trigger)
will show where the thread is; that'd at least provide some more concrete
information if the thread is really stuck somewhere.


> Thank you!
> _______________________________________________ xfs mailing list 
> xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs

<Prev in Thread] Current Thread [Next in Thread>
  • xfsdump, William Moss
    • Re: xfsdump, Eric Sandeen <=