|To:||Christoph Hellwig <hch@xxxxxxxxxxxxx>|
|Subject:||Re: Kernel 184.108.40.206 XFS(..?) regression (happened again)|
|From:||Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>|
|Date:||Mon, 17 Aug 2009 10:25:22 -0400 (EDT)|
|Cc:||Felix Blyakher <felixb@xxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx|
|References:||<alpine.DEB.2.00.0908080422440.12329@xxxxxxxxxxxxxxxx> <00980BBF-1206-4BEF-A8AE-B4A8DAE7EC27@xxxxxxx> <alpine.DEB.2.00.0908090605080.16485@xxxxxxxxxxxxxxxx> <alpine.DEB.2.00.0908110624420.22426@xxxxxxxxxxxxxxxx> <20090816022331.GA2309@xxxxxxxxxxxxx>|
|User-agent:||Alpine 2.00 (DEB 1167 2008-08-23)|
On Sat, 15 Aug 2009, Christoph Hellwig wrote:
All your traces seem to have in common that you're block on locks hold by processed doing I/O. Especially a lot of page locks which are controlled by the VM and not the filesystem. Can you try with commit 8aa7e847d834ed937a9ad37a0f2ad5b8584c1ab0 from 2.6.31-rc applied, or better directly 2.6.3-rc6? I would be surprised if this is something inside XFS, but running with CONFIG_XFS_DEBUG never hurts.
Christoph, Thanks, running with DEBUG and 2.6.31-rc6. CONFIG_XFS_DEBUG=y So far the problem has not surfaced, but it normally takes 24-48 hours. Justin.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||"Advertise at no extra cost", marketing|
|Next by Date:||Re: XFS corruption with failover, John Quigley|
|Previous by Thread:||Re: Kernel 220.127.116.11 XFS(..?) regression (happened again), Christoph Hellwig|
|Next by Thread:||Re: Kernel 18.104.22.168 XFS(..?) regression (& with/2.6.31-rc6), Justin Piszcz|
|Indexes:||[Date] [Thread] [Top] [All Lists]|