public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v3 08/11] xfs: update the finobt on inode free
Date: Tue, 11 Feb 2014 18:31:03 +1100	[thread overview]
Message-ID: <20140211073103.GI13647@dastard> (raw)
In-Reply-To: <1391536182-9048-9-git-send-email-bfoster@redhat.com>

On Tue, Feb 04, 2014 at 12:49:39PM -0500, Brian Foster wrote:
> An inode free operation can have several effects on the finobt. If
> all inodes have been freed and the chunk deallocated, we remove the
> finobt record. If the inode chunk was previously full, we must
> insert a new record based on the existing inobt record. Otherwise,
> we modify the record in place.
> 
> Create the xfs_ifree_finobt() function to identify the potential
> scenarios and update the finobt appropriately.

Couple of minor things....

> +	 * Read and update the existing record.
> +	 */
> +	error = xfs_inobt_get_rec(cur, &rec, &i);
> +	if (error)
> +		goto error;
> +	XFS_WANT_CORRUPTED_GOTO(i == 1, error);
> +
> +	rec.ir_free |= XFS_INOBT_MASK(offset);
> +	rec.ir_freecount++;
> +
> +	XFS_WANT_CORRUPTED_GOTO((rec.ir_free == ibtrec->ir_free) &&
> +				(rec.ir_freecount == ibtrec->ir_freecount),
> +				error);

I'd add a small comment here saying:

	/*
	 * We could just copy the ibtrec across here, but that
	 * defeats the purpose of having redundant metadata. By
	 * doing the modifications independently, we can catch
	 * corruptions that we wouldn't see if we just copied from
	 * one record to another.
	 */

> +	/*
> +	 * The content of inobt records should always match between the inobt
> +	 * and finobt. The lifecycle of records in the finobt is different from
> +	 * the inobt in that the finobt only tracks records with at least one
> +	 * free inode. This is to optimize lookup for inode allocation purposes.
> +	 * The following checks determine whether to update the existing record or
> +	 * remove it entirely.
> +	 */
> +

extra whitespace line

> +	if (rec.ir_freecount == XFS_IALLOC_INODES(mp) &&
> +	    !(mp->m_flags & XFS_MOUNT_IKEEP)) {
> +		/*
> +		 * If all inodes are free and we're in !ikeep mode, the entire
> +		 * inode chunk has been deallocated. Remove the record from the
> +		 * finobt.
> +		 */
> +		error = xfs_btree_delete(cur, &i);
> +		if (error)
> +			goto error;
> +		ASSERT(i == 1);
> +	} else {
> +		/*
> +		 * The existing finobt record was modified and has a combination
> +		 * of allocated and free inodes or is completely free and ikeep
> +		 * is enabled. Update the record.
> +		 */
> +		error = xfs_inobt_update(cur, &rec);
> +		if (error)
> +			goto error;
> +	}

All th comments say pretty much the same thing, and repeat what the
code does. Hence I think this is sufficient:

	/*
	 * The content of inobt records should always match between the inobt
	 * and finobt. The lifecycle of records in the finobt is different from
	 * the inobt in that the finobt only tracks records with at least one
	 * free inode. Hence if all the inodes are free and we aren't keeping
	 * inode chunks permanently on disk, remove them. Otherwise just
	 * update the record with the new information.
	 */
	if (rec.ir_freecount == XFS_IALLOC_INODES(mp) &&
	    !(mp->m_flags & XFS_MOUNT_IKEEP)) {
		error = xfs_btree_delete(cur, &i);
		if (error)
			goto error;
		ASSERT(i == 1);
	} else {
		error = xfs_inobt_update(cur, &rec);
		if (error)
			goto error;
	}

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2014-02-11  7:31 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-04 17:49 [PATCH v3 00/11] xfs: introduce the free inode btree Brian Foster
2014-02-04 17:49 ` [PATCH v3 01/11] xfs: refactor xfs_ialloc_btree.c to support multiple inobt numbers Brian Foster
2014-02-04 17:49 ` [PATCH v3 02/11] xfs: reserve v5 superblock read-only compat. feature bit for finobt Brian Foster
2014-02-11  6:07   ` Dave Chinner
2014-02-04 17:49 ` [PATCH v3 03/11] xfs: support the XFS_BTNUM_FINOBT free inode btree type Brian Foster
2014-02-11  6:22   ` Dave Chinner
2014-02-04 17:49 ` [PATCH v3 04/11] xfs: update inode allocation/free transaction reservations for finobt Brian Foster
2014-02-11  6:46   ` Dave Chinner
2014-02-11 16:22     ` Brian Foster
2014-02-20  1:00       ` Dave Chinner
2014-02-20 16:04         ` Brian Foster
2014-02-18 17:10     ` Brian Foster
2014-02-18 20:34       ` Brian Foster
2014-02-20  2:01       ` Dave Chinner
2014-02-20 18:49         ` Brian Foster
2014-02-20 20:50           ` Dave Chinner
2014-02-20 21:14           ` Christoph Hellwig
2014-02-20 23:13             ` Dave Chinner
2014-02-04 17:49 ` [PATCH v3 05/11] xfs: insert newly allocated inode chunks into the finobt Brian Foster
2014-02-11  6:48   ` Dave Chinner
2014-02-04 17:49 ` [PATCH v3 06/11] xfs: use and update the finobt on inode allocation Brian Foster
2014-02-11  7:17   ` Dave Chinner
2014-02-11 16:32     ` Brian Foster
2014-02-14 20:01     ` Brian Foster
2014-02-20  0:38       ` Dave Chinner
2014-02-04 17:49 ` [PATCH v3 07/11] xfs: refactor xfs_difree() inobt bits into xfs_difree_inobt() helper Brian Foster
2014-02-11  7:19   ` Dave Chinner
2014-02-04 17:49 ` [PATCH v3 08/11] xfs: update the finobt on inode free Brian Foster
2014-02-11  7:31   ` Dave Chinner [this message]
2014-02-04 17:49 ` [PATCH v3 09/11] xfs: add finobt support to growfs Brian Foster
2014-02-04 17:49 ` [PATCH v3 10/11] xfs: report finobt status in fs geometry Brian Foster
2014-02-11  7:34   ` Dave Chinner
2014-02-04 17:49 ` [PATCH v3 11/11] xfs: enable the finobt feature on v5 superblocks Brian Foster
2014-02-11  7:34   ` 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=20140211073103.GI13647@dastard \
    --to=david@fromorbit.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