From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Subject: [PATCH 05/15] xfs: don't do IO when creating an new inode
Date: Thu, 27 Jun 2013 16:04:49 +1000 [thread overview]
Message-ID: <1372313099-8121-6-git-send-email-david@fromorbit.com> (raw)
In-Reply-To: <1372313099-8121-1-git-send-email-david@fromorbit.com>
From: Dave Chinner <dchinner@redhat.com>
When we are allocating a new inode, we read the inode cluster off
disk to increment the generation number. We are already using a
random generation number for newly allocated inodes, so if we are not
using the ikeep mode, we can just generate a new generation number
when we initialise the newly allocated inode.
This avoids the need for reading the inode buffer during inode
creation. This will speed up allocation of inodes in cold, partially
allocated clusters as they will no longer need to be read from disk
during allocation. It will also reduce the CPU overhead of inode
allocation by not having the process the buffer read, even on cache
hits.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
---
fs/xfs/xfs_inode.c | 36 ++++++++++++++++++++++++++++--------
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index 7f7be5f..d1f76da 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -1028,6 +1028,11 @@ xfs_dinode_calc_crc(
/*
* Read the disk inode attributes into the in-core inode structure.
+ *
+ * If we are initialising a new inode and we are not utilising the
+ * XFS_MOUNT_IKEEP inode cluster mode, we can simple build the new inode core
+ * with a random generation number. If we are keeping inodes around, we need to
+ * read the inode cluster to get the existing generation number off disk.
*/
int
xfs_iread(
@@ -1047,6 +1052,22 @@ xfs_iread(
if (error)
return error;
+ /* shortcut IO on inode allocation if possible */
+ if ((iget_flags & XFS_IGET_CREATE) &&
+ !(mp->m_flags & XFS_MOUNT_IKEEP)) {
+ /* initialise the on-disk inode core */
+ memset(&ip->i_d, 0, sizeof(ip->i_d));
+ ip->i_d.di_magic = XFS_DINODE_MAGIC;
+ ip->i_d.di_gen = prandom_u32();
+ if (xfs_sb_version_hascrc(&mp->m_sb)) {
+ ip->i_d.di_version = 3;
+ ip->i_d.di_ino = ip->i_ino;
+ uuid_copy(&ip->i_d.di_uuid, &mp->m_sb.sb_uuid);
+ } else
+ ip->i_d.di_version = 2;
+ return 0;
+ }
+
/*
* Get pointers to the on-disk inode and the buffer containing it.
*/
@@ -1133,17 +1154,16 @@ xfs_iread(
xfs_buf_set_ref(bp, XFS_INO_REF);
/*
- * Use xfs_trans_brelse() to release the buffer containing the
- * on-disk inode, because it was acquired with xfs_trans_read_buf()
- * in xfs_imap_to_bp() above. If tp is NULL, this is just a normal
+ * Use xfs_trans_brelse() to release the buffer containing the on-disk
+ * inode, because it was acquired with xfs_trans_read_buf() in
+ * xfs_imap_to_bp() above. If tp is NULL, this is just a normal
* brelse(). If we're within a transaction, then xfs_trans_brelse()
* will only release the buffer if it is not dirty within the
* transaction. It will be OK to release the buffer in this case,
- * because inodes on disk are never destroyed and we will be
- * locking the new in-core inode before putting it in the hash
- * table where other processes can find it. Thus we don't have
- * to worry about the inode being changed just because we released
- * the buffer.
+ * because inodes on disk are never destroyed and we will be locking the
+ * new in-core inode before putting it in the cache where other
+ * processes can find it. Thus we don't have to worry about the inode
+ * being changed just because we released the buffer.
*/
out_brelse:
xfs_trans_brelse(tp, bp);
--
1.7.10.4
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-06-27 6:05 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-27 6:04 [PATCH 00/15] xfs: patchset for 3.11 Dave Chinner
2013-06-27 6:04 ` [PATCH 01/15] xfs: update mount options documentation Dave Chinner
2013-06-27 14:48 ` Ben Myers
2013-06-27 19:08 ` Ben Myers
2013-06-28 2:09 ` Dave Chinner
2013-06-28 2:32 ` Dave Chinner
2013-06-28 15:39 ` Geoffrey Wehrman
2013-06-28 16:49 ` Eric Sandeen
2013-06-28 19:58 ` Geoffrey Wehrman
2013-06-28 17:27 ` Ric Wheeler
2013-06-28 19:39 ` Ben Myers
2013-06-29 2:38 ` Dave Chinner
2013-06-28 2:18 ` Eric Sandeen
2013-06-28 20:46 ` Ben Myers
2013-06-27 6:04 ` [PATCH 02/15] xfs: add pluging for bulkstat readahead Dave Chinner
2013-06-27 6:04 ` [PATCH 03/15] xfs: plug directory buffer readahead Dave Chinner
2013-06-27 6:04 ` [PATCH 04/15] xfs: don't use speculative prealloc for small files Dave Chinner
2013-06-27 6:04 ` Dave Chinner [this message]
2013-06-27 6:04 ` [PATCH 06/15] xfs: xfs_ifree doesn't need to modify the inode buffer Dave Chinner
2013-06-27 6:04 ` [PATCH 07/15] xfs: Introduce ordered log vector support Dave Chinner
2013-06-27 6:04 ` [PATCH 08/15] xfs: Introduce an ordered buffer item Dave Chinner
2013-06-27 6:04 ` [PATCH 09/15] xfs: Inode create log items Dave Chinner
2013-06-27 6:04 ` [PATCH 10/15] xfs: Inode create transaction reservations Dave Chinner
2013-06-27 6:04 ` [PATCH 11/15] xfs: Inode create item recovery Dave Chinner
2013-06-27 6:04 ` [PATCH 12/15] xfs: Use inode create transaction Dave Chinner
2013-06-27 6:04 ` [PATCH 13/15] xfs: remove local fork format handling from xfs_bmapi_write() Dave Chinner
2013-06-27 6:04 ` [PATCH 14/15] xfs: dquot log reservations are too small Dave Chinner
2013-06-27 14:38 ` Mark Tinguely
2013-06-28 17:18 ` Chandra Seetharaman
2013-06-29 2:42 ` Dave Chinner
2013-07-09 19:31 ` Ben Myers
2013-07-09 20:39 ` Dave Chinner
2013-07-09 20:42 ` Ben Myers
2013-06-27 6:04 ` [PATCH 15/15] xfs: implement inode change count Dave Chinner
2013-06-27 15:06 ` Mark Tinguely
2013-06-28 16:07 ` Chandra Seetharaman
2013-06-28 18:00 ` Ben Myers
2013-06-27 19:48 ` [PATCH 00/15] xfs: patchset for 3.11 Ben Myers
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=1372313099-8121-6-git-send-email-david@fromorbit.com \
--to=david@fromorbit.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