linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Tinguely <tinguely@sgi.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 1/2] xfs: remove efi from AIL in log recovery error
Date: Fri, 28 Mar 2014 10:41:06 -0500	[thread overview]
Message-ID: <53359812.3090806@sgi.com> (raw)
In-Reply-To: <20140328152434.GB21961@bfoster.bfoster>

On 03/28/14 10:24, Brian Foster wrote:
> On Tue, Mar 25, 2014 at 03:06:34PM -0500, Mark Tinguely wrote:
>> xlog_recover_process_efi{s}() functions are completing the
>> second half of xfs_bmap_finish() which frees extents. If this
>> operation fails, the EFI will stay on the AIL and prevents
>> the xfs_ail_push all_sync() from completing and the mount will
>> fail to unmount.
>>
>> Rather than have a special log recovery flag XFS_EFI_RECOVERED
>> to decrement the EFI/EFD counter, call the same decrement function
>> from the log recovery routine that is called then the EFI is added
>> to the AIL from a log write.
>>
>> Remove all other unprocessed EFIs from the log recovery AIL
>> when one is discovered in error.
>>
>> Signed-off-by: Mark Tinguely<tinguely@sgi.com>
>> ---
>> Rewritten with suggestions from Dave.
>> Note: calling xfs_efi_item_unpin() seemed more explainatory than calling
>>        the helper __xfs_efi_release().
>>
>>   fs/xfs/xfs_extfree_item.c |    9 +++------
>>   fs/xfs/xfs_log_recover.c  |   28 +++++++++++++++-------------
>>   fs/xfs/xfs_trans.h        |    1 +
>>   3 files changed, 19 insertions(+), 19 deletions(-)
>>
>> Index: b/fs/xfs/xfs_extfree_item.c
>> ===================================================================
>> --- a/fs/xfs/xfs_extfree_item.c
>> +++ b/fs/xfs/xfs_extfree_item.c
>> @@ -134,9 +134,10 @@ xfs_efi_item_pin(
>>    * remove the EFI it's because the transaction has been canceled and by
>>    * definition that means the EFI cannot be in the AIL so remove it from the
>>    * transaction and free it.  Otherwise coordinate with xfs_efi_release()
>> - * to determine who gets to free the EFI.
>> + * to determine who gets to free the EFI. Call from log recovery of EFI
>> + * entries so the EFD or error handling will remove the entry.
>>    */
>> -STATIC void
>> +void
>>   xfs_efi_item_unpin(
>>   	struct xfs_log_item	*lip,
>>   	int			remove)
>> @@ -313,10 +314,6 @@ xfs_efi_release(xfs_efi_log_item_t	*efip
>>   {
>>   	ASSERT(atomic_read(&efip->efi_next_extent)>= nextents);
>>   	if (atomic_sub_and_test(nextents,&efip->efi_next_extent)) {
>> -		/* recovery needs us to drop the EFI reference, too */
>> -		if (test_bit(XFS_EFI_RECOVERED,&efip->efi_flags))
>> -			__xfs_efi_release(efip);
>> -
>>   		__xfs_efi_release(efip);
>>   		/* efip may now have been freed, do not reference it again. */
>>   	}
>> Index: b/fs/xfs/xfs_log_recover.c
>> ===================================================================
>> --- a/fs/xfs/xfs_log_recover.c
>> +++ b/fs/xfs/xfs_log_recover.c
>> @@ -3634,6 +3634,7 @@ xlog_recover_process_data(
>>   /*
>>    * Process an extent free intent item that was recovered from
>>    * the log.  We need to free the extents that it describes.
>> + * The caller will release this and any following EFIs upon error.
>>    */
>>   STATIC int
>>   xlog_recover_process_efi(
>> @@ -3648,6 +3649,13 @@ xlog_recover_process_efi(
>>   	xfs_fsblock_t		startblock_fsb;
>>
>>   	ASSERT(!test_bit(XFS_EFI_RECOVERED,&efip->efi_flags));
>> +	set_bit(XFS_EFI_RECOVERED,&efip->efi_flags);
>> +
>> +	/*
>> +	 * Decrement the EFI/EFD counter so the EFI is removed after
>> +	 * processing the EFD or error handling in the caller.
>> +	 */
>> +	xfs_efi_item_unpin(&efip->efi_item, 0);
>>
>>   	/*
>>   	 * First check the validity of the extents described by the
>> @@ -3662,12 +3670,6 @@ xlog_recover_process_efi(
>>   		    (extp->ext_len == 0) ||
>>   		    (startblock_fsb>= mp->m_sb.sb_dblocks) ||
>>   		    (extp->ext_len>= mp->m_sb.sb_agblocks)) {
>> -			/*
>> -			 * This will pull the EFI from the AIL and
>> -			 * free the memory associated with it.
>> -			 */
>> -			set_bit(XFS_EFI_RECOVERED,&efip->efi_flags);
>> -			xfs_efi_release(efip, efip->efi_format.efi_nextents);
>>   			return XFS_ERROR(EIO);
>>   		}
>>   	}
>> @@ -3687,7 +3689,6 @@ xlog_recover_process_efi(
>>   					 extp->ext_len);
>>   	}
>>
>> -	set_bit(XFS_EFI_RECOVERED,&efip->efi_flags);
>>   	error = xfs_trans_commit(tp, 0);
>>   	return error;
>>
>> @@ -3718,8 +3719,8 @@ STATIC int
>>   xlog_recover_process_efis(
>>   	struct xlog	*log)
>>   {
>> -	xfs_log_item_t		*lip;
>> -	xfs_efi_log_item_t	*efip;
>> +	struct xfs_log_item	*lip;
>> +	struct xfs_efi_log_item	*efip;
>>   	int			error = 0;
>>   	struct xfs_ail_cursor	cur;
>>   	struct xfs_ail		*ailp;
>> @@ -3750,13 +3751,14 @@ xlog_recover_process_efis(
>>   		}
>>
>>   		spin_unlock(&ailp->xa_lock);
>> -		error = xlog_recover_process_efi(log->l_mp, efip);
>> -		spin_lock(&ailp->xa_lock);
>> +		/* Skip all EFIs after first EFI in error. */
>> +		if (!error)
>> +			error = xlog_recover_process_efi(log->l_mp, efip);
>>   		if (error)
>> -			goto out;
>> +			xfs_efi_release(efip, efip->efi_format.efi_nextents);
>
> Hi Mark,
>
> If we hit the scenario where we start skipping EFIs after an error, is
> the equivalent unpin() call from process_efi() not necessary on the
> subsequent EFIs?
>
> Brian

yes, good catch. They will have to be decremented twice. something like:
+		if (!error)
+			error = xlog_recover_process_efi(log->l_mp, efip);
+		else
+			xfs_efi_item_unpin(&efip->efi_item, 0);
+		if (error)
...

--Mark

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2014-03-28 15:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-25 20:06 [PATCH 0/2] xfs: Clean the EFI on errors series Mark Tinguely
2014-03-25 20:06 ` [PATCH 1/2] xfs: remove efi from AIL in log recovery error Mark Tinguely
2014-03-28 15:24   ` Brian Foster
2014-03-28 15:41     ` Mark Tinguely [this message]
2014-03-28 16:07       ` Brian Foster
2014-03-28 16:21         ` Mark Tinguely
2014-03-31 20:25   ` [PATCH v2 1/2] xfs: remove efi from AIL in log recovery Mark Tinguely
2014-04-03 19:07     ` Dave Chinner
2014-03-25 20:06 ` [PATCH 2/2] xfs: free the EFI entries from AIL on forced shutdown Mark Tinguely
2014-04-03 19:34   ` Dave Chinner
2014-04-03 20:48     ` Mark Tinguely
2014-04-03 21:53       ` Dave Chinner

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=53359812.3090806@sgi.com \
    --to=tinguely@sgi.com \
    --cc=bfoster@redhat.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).