On Wed, Jan 31, 2007 at 12:39:33AM -0800, Andrew Morton wrote:
>
> See http://bugzilla.kernel.org/show_bug.cgi?id=7364
>
> This guy has XFS deadlocks. And stack overruns, but we knew about that.
>
> Perhaps the deadlocks are due to NBD?
The first set of traces show:
- pdflush trying to write the superblock and sleeping because
the superblock buffer is pinned in memory.
- a create waiting for the superblock buffer lock so
it can include the superblock in a transaction
The create is backed up behind superblock write, but hte superblock
write can't make progress until the the pinned buffer is unpinned
during I/O completion of the log buffer that contains the
transaction that the superblock modification was recorded in. So it
would appear we are hung up waiting for I/O to complete.
And in the 2.6.18.1 trace we have:
- rm doing an inode read from disk which is waiting for
I/O completion.
- pdflush trying to write the superblock and sleeping because
the superblock buffer is pinned in memory.
If the inode read wasn't a give-away, the pdflush thread should make
it is obvious we are hung up waiting for I/O completion.
And from 2.6.19-rc3, we have a pdflush thread asleep in
xlog_state_get_iclog_space() waiting for a in-core log buffer to
become available so it can commit an allocation transaction to the
log. We only wait here when all the iclog buffers are under I/O
and we have to wait for them to complete their I/O.....
So, there's no deadlocks in XFS here - XFs is simply waiting for the
I/O it issued to complete. I think this pretty clearly indicates an
NBD problem.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
|