public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Chandan Rajendra <chandan@linux.vnet.ibm.com>
To: dchinner@redhat.com
Cc: linux-xfs <linux-xfs@vger.kernel.org>,
	"sandeen@sandeen.net" <sandeen@sandeen.net>,
	"Darrick J . Wong" <darrick.wong@oracle.com>
Subject: Clarification on inode alignment
Date: Thu, 23 Feb 2017 11:51:12 +0530	[thread overview]
Message-ID: <1735943.rpnT4cuqyx@localhost.localdomain> (raw)

Hi Dave,

Last week, during a discussion on #xfs you stated that,

"inode alignment is necessary to avoid needing to do an inobt lookup to find
the location of the inode every time we map an inode to disk".

Also, The following statement appears at
http://xfs.org/index.php/Improving_inode_Caching,

"The main problem we have is that XFS uses inode chunk size and alignment to
optimise inode number to disk location conversion. That is, the conversion
becomes a single set of shifts and masks instead of an AGI btree lookup. This
optimisation substantially reduces the CPU and I/O overhead of inode lookups,
but it does limit our flexibility. If we break the alignment restriction,
every lookup has to go back to a btree search. Hence we really want to avoid
breaking chunk alignment and size rules."

For the 4k block size scenario, I noticed that we have inode alignment of 4
blocks. I did go through macros such as XFS_INO_TO_AGNO(),
XFS_INO_TO_AGBNO() and XFS_INO_TO_OFFSET() which deal with extracting the
components from an inode number.

However I still don't understand how non-aligned inode clusters (64 inodes in
a single cluster) would break the inode number to disk location
arithmetic calculations. Could you please explain it?

-- 
chandan


             reply	other threads:[~2017-02-23  8:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-23  6:21 Chandan Rajendra [this message]
2017-02-24  0:08 ` Clarification on inode alignment Dave Chinner
2017-02-24 10:24   ` Chandan Rajendra

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=1735943.rpnT4cuqyx@localhost.localdomain \
    --to=chandan@linux.vnet.ibm.com \
    --cc=darrick.wong@oracle.com \
    --cc=dchinner@redhat.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /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