All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH V2] xfs: create helper for bmap finish & trans join in attr code
Date: Mon, 4 Jan 2016 14:58:40 +1100	[thread overview]
Message-ID: <20160104035840.GA19802@dastard> (raw)
In-Reply-To: <56465643.5070504@sandeen.net>

On Fri, Nov 13, 2015 at 03:29:39PM -0600, Eric Sandeen wrote:
> On 11/13/15 3:08 AM, Christoph Hellwig wrote:
> > On Fri, Nov 13, 2015 at 07:12:31AM +1100, Dave Chinner wrote:
> >> On Thu, Nov 12, 2015 at 08:58:01AM -0800, Christoph Hellwig wrote:
> >>> I think the problem here is simply that our interfaces suck.
> >>> xfs_trans_roll really needs to rejoin any inode to the new transaction
> >>> to that was joined to the previous one.  Once we've fixed that we can
> >>> get rid of the silly committed arguments and everyone will be happy.
> >>
> >> xfs_trans_roll is not specifically for rolling transactions with
> >> locked inodes in them. We could use it for any object that needs
> >> multiple transactions to modify. e.g. we could roll transactions
> >> across an AGF (using hold+join) so that it remains locked across
> >> multiple allocation/free transactions.
> > 
> > xfs_trans_roll already logs the inode core, which requires the
> > inode to be attached to the transaction.  While I could see the
> > point of moving this out of the core __xfs_trans_roll into an
> > xfs_trans_roll_inode helper we might as well follow the current
> > interface for now.
> 
> Trying to follow you guys ;)
> 
> Something like this?

yes, something like that ;)

(better late than never!)

-Dave.

> diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
> index dbae649..d23bce8 100644
> --- a/fs/xfs/xfs_bmap_util.c
> +++ b/fs/xfs/xfs_bmap_util.c
> @@ -91,32 +91,32 @@ xfs_zero_extent(
>   * last due to locking considerations.  We never free any extents in
>   * the first transaction.
>   *
> - * Return 1 if the given transaction was committed and a new one
> - * started, and 0 otherwise in the committed parameter.
> + * If an inode *ip is provided, rejoin it to the transaction if
> + * the transaction was committed.
>   */
>  int						/* error */
>  xfs_bmap_finish(
>  	struct xfs_trans		**tp,	/* transaction pointer addr */
>  	struct xfs_bmap_free		*flist,	/* i/o: list extents to free */
> -	int				*committed)/* xact committed or not */
> +	xfs_inode_t			*ip)
>  {
>  	struct xfs_efd_log_item		*efd;	/* extent free data */
>  	struct xfs_efi_log_item		*efi;	/* extent free intention */
>  	int				error;	/* error return value */
> +	int				committed;/* xact committed or not */
>  	struct xfs_bmap_free_item	*free;	/* free extent item */
>  	struct xfs_bmap_free_item	*next;	/* next item on free list */
>  
>  	ASSERT((*tp)->t_flags & XFS_TRANS_PERM_LOG_RES);
> -	if (flist->xbf_count == 0) {
> -		*committed = 0;
> +	if (flist->xbf_count == 0)
>  		return 0;
> -	}
> +
>  	efi = xfs_trans_get_efi(*tp, flist->xbf_count);
>  	for (free = flist->xbf_first; free; free = free->xbfi_next)
>  		xfs_trans_log_efi_extent(*tp, efi, free->xbfi_startblock,
>  			free->xbfi_blockcount);
>  
> -	error = __xfs_trans_roll(tp, NULL, committed);
> +	error = __xfs_trans_roll(tp, ip, &committed);
>  	if (error) {
>  		/*
>  		 * If the transaction was committed, drop the EFD reference
> @@ -128,16 +128,13 @@ xfs_bmap_finish(
>  		 * transaction so we should return committed=1 even though we're
>  		 * returning an error.
>  		 */
> -		if (*committed) {
> +		if (committed) {
>  			xfs_efi_release(efi);
>  			xfs_force_shutdown((*tp)->t_mountp,
>  				(error == -EFSCORRUPTED) ?
>  					SHUTDOWN_CORRUPT_INCORE :
>  					SHUTDOWN_META_IO_ERROR);
> -		} else {
> -			*committed = 1;
>  		}
> -
>  		return error;
>  	}
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2016-01-04  3:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-12  4:54 [PATCH] xfs: create helper for bmap finish & trans join in xfs_attr.c Eric Sandeen
2015-11-12  4:58 ` Eric Sandeen
2015-11-12 16:31 ` [PATCH V2] xfs: create helper for bmap finish & trans join in attr code Eric Sandeen
2015-11-12 16:58   ` Christoph Hellwig
2015-11-12 20:12     ` Dave Chinner
2015-11-13  9:08       ` Christoph Hellwig
2015-11-13 21:29         ` Eric Sandeen
2016-01-04  3:58           ` Dave Chinner [this message]
2016-01-05 19:01   ` [PATCH V3] xfs: eliminate committed arg from xfs_bmap_finish Eric Sandeen
2016-01-06  3:28     ` Dave Chinner
2016-01-06  4:01     ` [PATCH V4] " Eric Sandeen
2016-01-06  5:31       ` Christoph Hellwig

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=20160104035840.GA19802@dastard \
    --to=david@fromorbit.com \
    --cc=sandeen@sandeen.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.