From: Mark Tinguely <tinguely@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: "Mears, Morgan" <Morgan.Mears@netapp.com>,
Jie Liu <jeff.liu@oracle.com>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: Possible XFS bug encountered in 3.14.0-rc3+
Date: Thu, 13 Mar 2014 10:03:33 -0500 [thread overview]
Message-ID: <5321C8C5.2020506@sgi.com> (raw)
In-Reply-To: <20140312230631.GF6851@dastard>
On 03/12/14 18:06, Dave Chinner wrote:
> On Wed, Mar 12, 2014 at 04:43:26PM -0500, Mark Tinguely wrote:
>> On 03/12/14 15:14, Mears, Morgan wrote:
>>> I was unable to umount, even with -f; failed with EBUSY and couldn't unbusy
>>> as the fs was unresponsive (and happens to contain the Oracle management
>>> tools necessary to close all open descriptors). Accordingly I rebooted.
>>
>> You are the second person in 2-3 weeks to hit this unmount issue.
>> Unmatched EFI in the AIL keeps the unmount from completing.
>>
>> Jeff are you still looking at this?
>
> I'd say the answer is no. Last time you pointed out this problem I
> last asked you to provide patches to fix the problem, mark. Can
> you please provide patches to fix this, Mark?
>
> Cheers,
>
> Dave.
Ah, you wanted me to fix the cil_push error issue that leaks ctx and
does not wake up the waiters. This is only a side issue to that.
We can easily patch the xfs_bmap_finish() and
xlog_recover_process_efis() code. I have that patch and tested it. But
it does not cover the cases of a cil push error nor the successful
xfs_bmap_finish() and the EFI is in the AIL but the EFD is discarded.
The most correct thing to do is clear the EFI from the AIL in the abort
paths of xfs_efd_item_committed() and xfs_efd_item_unlock(), but those
will be called many times and would be overkill.
A less correct but easier would be clear the EFIs from the AIL once in
xfs_unmountfs() after the last force of the log and before the
xfs_ail_push_all_sync(). Since the EFI are removed very late, then we
don't have to special case the removal in xfs_bmap_finish() and the
xlog_recover_process_efis(). This is why I was waiting to see what Jeff
wanted to do.
If I hear no strong objection, I intend to put the clearing EFI on the
AIL for each situation: the abort cases of the efd iop routines, in
xfs_bmap_finish() and the xlog_recover_process_efis().
--Mark.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-03-13 15:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-12 20:14 Possible XFS bug encountered in 3.14.0-rc3+ Mears, Morgan
2014-03-12 21:43 ` Mark Tinguely
2014-03-12 23:06 ` Dave Chinner
2014-03-13 15:03 ` Mark Tinguely [this message]
2014-03-12 23:02 ` Dave Chinner
2014-03-13 14:47 ` Mears, Morgan
2014-03-13 15:31 ` Ben Myers
2014-03-13 16:56 ` Mears, Morgan
2014-03-13 22:58 ` Dave Chinner
2014-03-14 14:22 ` Mears, Morgan
2014-03-24 21:36 ` Mark Tinguely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5321C8C5.2020506@sgi.com \
--to=tinguely@sgi.com \
--cc=Morgan.Mears@netapp.com \
--cc=david@fromorbit.com \
--cc=jeff.liu@oracle.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).