| To: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: Kernel 2.6.30.4 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 |
| In-reply-to: | <20090816022331.GA2309@xxxxxxxxxxxxx> |
| 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. |
| Previous by Date: | "Advertise at no extra cost", marketing |
|---|---|
| Next by Date: | Re: XFS corruption with failover, John Quigley |
| Previous by Thread: | Re: Kernel 2.6.30.4 XFS(..?) regression (happened again), Christoph Hellwig |
| Next by Thread: | Re: Kernel 2.6.30.4 XFS(..?) regression (& with/2.6.31-rc6), Justin Piszcz |
| Indexes: | [Date] [Thread] [Top] [All Lists] |