public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: David Chinner <dgc@sgi.com>
Cc: xfs-dev <xfs-dev@sgi.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: review [1 of 3]: lazy superblock counters - core kernel
Date: Mon, 23 Apr 2007 23:00:10 +0100	[thread overview]
Message-ID: <20070423220010.GA18325@infradead.org> (raw)
In-Reply-To: <20070419231459.GX48531920@melbourne.sgi.com>

> -		if ((error = xfs_alloc_get_freelist(args->tp, args->agbp, &fbno)))
> +		error = xfs_alloc_get_freelist(args->tp, args->agbp, &fbno, 0);
> +		if (error)

Nice cleanup here.

> -		if ((error = xfs_alloc_get_freelist(tp, agbp, &bno)))
> +		if ((error = xfs_alloc_get_freelist(tp, agbp, &bno, 0)))

but not here.  Any chance you could use the linux kernel prefered style in the first
hunk everywhere?  Especially in new code where the patch uses the second style aswell.

> +#define XFS_SB_VERSION2_LAZYSBCOUNTBIT	0x00000002	/* Superblk counters */

The flag seems a bit misnamed to me.  It's really about counting the freelist
blocks, not the lazy counters that require it.  But given that it's been in
IRIX for a while that's probably not something we could change.

> +#define XFS_SB_VERSION_LAZYSBCOUNT(sbp)	xfs_sb_version_haslazysbcount(sbp)
> +static inline int xfs_sb_version_haslazysbcount(xfs_sb_t *sbp)

Please just use the inline version everywhere and don't introduce the
uppercase superflous macro.

> +		 * Write into superblock the fields that we haven't
> +		 * been logging - allocated/free inode and free block
> +		 * counts - from the incore superblock.
> + 		 */
> +		error = xfs_log_sbcount(mp, (XFS_LOG_FORCE|XFS_LOG_SYNC));
>  
> -		xfs_icsb_sync_counters(mp);
> +		sbp = xfs_getsb(mp, 0);
> + 		sb = XFS_BUF_TO_SBP(sbp);
> +		if (error) {
> +			/*
> +			 * Hmmm - failed to get log reservations so just
> +			 * do the mod without a transaction. Whine about
> +			 * it, too.
> +			 */
> +			ASSERT(XFS_SB_VERSION_LAZYSBCOUNT(&mp->m_sb));
> +			xfs_fs_cmn_err(CE_NOTE, mp,
> +				"Unmounting, non-transactional sb update");
> +			s = XFS_SB_LOCK(mp);
> +			INT_SET(sb->sb_icount, ARCH_CONVERT, mp->m_sb.sb_icount);
> +			INT_SET(sb->sb_ifree, ARCH_CONVERT, mp->m_sb.sb_ifree);
> +			INT_SET(sb->sb_fdblocks, ARCH_CONVERT, mp->m_sb.sb_fdblocks);
> +			XFS_SB_UNLOCK(mp, s);

This is really quite nasty.  Should we at least force a cache flush here?

> +	 *
> +	 * We also update the disk superblock with incore counter
> +	 * values if we are using non-persistent counters so that
> +	 * they don't get too far out of sync if we crash or get a
> +	 * forced shutdown. We don't want to force this to disk,
> +	 * just get a transaction into the iclogs....
>  	 */
>  	if (flags & SYNC_REFCACHE) {
>  		if (flags & SYNC_WAIT)
>  			xfs_refcache_purge_mp(mp);
>  		else
>  			xfs_refcache_purge_some(mp);
> +		xfs_log_sbcount(mp, 0);

Can you please give this a SYNC_ flag of it's own?  SYNC_REFCACHE is
misnamed for this, and I hope it will go away once we stop pretending
to support 2.4 builds.

  reply	other threads:[~2007-04-23 22:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-19 23:15 review [1 of 3]: lazy superblock counters - core kernel David Chinner
2007-04-23 22:00 ` Christoph Hellwig [this message]
2007-04-23 22:16   ` David Chinner
2007-04-23 22:23     ` Christoph Hellwig
2007-04-23 23:20       ` David Chinner
2007-04-24  1:28   ` David Chinner
2007-04-24  8:51     ` Christoph Hellwig
2007-04-24 14:16       ` David 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=20070423220010.GA18325@infradead.org \
    --to=hch@infradead.org \
    --cc=dgc@sgi.com \
    --cc=xfs-dev@sgi.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