xfs-masters
[Top] [All Lists]

[Bug 860] XFS filesystem crash

To: xfs-masters@xxxxxxxxxxx
Subject: [Bug 860] XFS filesystem crash
From: bugzilla-daemon@xxxxxxxxxxx
Date: Tue, 16 Feb 2010 06:01:40 -0600
Auto-submitted: auto-generated
In-reply-to: <bug-860-113@xxxxxxxxxxxxxxxx/bugzilla/>
References: <bug-860-113@xxxxxxxxxxxxxxxx/bugzilla/>
http://oss.sgi.com/bugzilla/show_bug.cgi?id=860


Nikanth Karthikesan <nikanth@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nikanth@xxxxxxxxx




--- Comment #11 from Nikanth Karthikesan <nikanth@xxxxxxxxx>  2010-02-16 
06:01:37 CST ---
The problem could be that, when xfsdatad is waiting for lock on the loop
mounted(nested inside another xfs) xfs file-system and pdflush holds an
xfs_ilock in the nested xfs and waits for the log to be flushed.
But pdflush's wait will not complete as xfsdatad is per-cpu and not per-mounted
file-system. For pdflush to recover, xfsdatad has to work on the items queued
for the underlying xfs filesystem, instead of working/waiting on the lock for
the nested file-system. This creates a deadlock.

See https://bugzilla.novell.com/show_bug.cgi?id=568319 for more logs to
analyze, and verify this.

If this is the case, this could be resolved, either by creating xfsdatad per
mounted file-system, or by imposing some kind of ordering/priority such that
the underlying filesystem's work is given higher priority

-- 
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

<Prev in Thread] Current Thread [Next in Thread>