From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Subject: [PATCH v6 02/18] xfs: update free inode record logic to support sparse inode records
Date: Mon, 2 Mar 2015 08:27:52 -0500 [thread overview]
Message-ID: <1425302888-4962-3-git-send-email-bfoster@redhat.com> (raw)
In-Reply-To: <1425302888-4962-1-git-send-email-bfoster@redhat.com>
xfs_difree_inobt() uses logic in a couple places that assume inobt
records refer to fully allocated chunks. Specifically, the use of
mp->m_ialloc_inos can cause problems for inode chunks that are sparsely
allocated. Sparse inode chunks can, by definition, define a smaller
number of inodes than a full inode chunk.
Fix the logic that determines whether an inode record should be removed
from the inobt to use the ir_free mask rather than ir_freecount. Fix the
agi counters modification to use ir_freecount to add the actual number
of inodes freed rather than assuming a full inode chunk.
Also make sure that we preserve the behavior to not remove inode chunks
if the block size is large enough for multiple inode chunks (e.g.,
bsize=64k, isize=512). This behavior was previously implicit in that in
such configurations, ir.freecount of a single record never matches
m_ialloc_inos. Hence, add some comments as well.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/xfs/libxfs/xfs_ialloc.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_ialloc.c b/fs/xfs/libxfs/xfs_ialloc.c
index a186831..3033099 100644
--- a/fs/xfs/libxfs/xfs_ialloc.c
+++ b/fs/xfs/libxfs/xfs_ialloc.c
@@ -1508,10 +1508,13 @@ xfs_difree_inobt(
rec.ir_freecount++;
/*
- * When an inode cluster is free, it becomes eligible for removal
+ * When an inode chunk is free, it becomes eligible for removal. Don't
+ * remove the chunk if the block size is large enough for multiple inode
+ * chunks (that might not be free).
*/
if (!(mp->m_flags & XFS_MOUNT_IKEEP) &&
- (rec.ir_freecount == mp->m_ialloc_inos)) {
+ rec.ir_free == XFS_INOBT_ALL_FREE &&
+ mp->m_sb.sb_inopblock <= XFS_INODES_PER_CHUNK) {
*deleted = 1;
*first_ino = XFS_AGINO_TO_INO(mp, agno, rec.ir_startino);
@@ -1521,7 +1524,7 @@ xfs_difree_inobt(
* AGI and Superblock inode counts, and mark the disk space
* to be freed when the transaction is committed.
*/
- ilen = mp->m_ialloc_inos;
+ ilen = rec.ir_freecount;
be32_add_cpu(&agi->agi_count, -ilen);
be32_add_cpu(&agi->agi_freecount, -(ilen - 1));
xfs_ialloc_log_agi(tp, agbp, XFS_AGI_COUNT | XFS_AGI_FREECOUNT);
@@ -1641,8 +1644,13 @@ xfs_difree_finobt(
* free inode. Hence, if all of the inodes are free and we aren't
* keeping inode chunks permanently on disk, remove the record.
* Otherwise, update the record with the new information.
+ *
+ * Note that we currently can't free chunks when the block size is large
+ * enough for multiple chunks. Leave the finobt record to remain in sync
+ * with the inobt.
*/
- if (rec.ir_freecount == mp->m_ialloc_inos &&
+ if (rec.ir_free == XFS_INOBT_ALL_FREE &&
+ mp->m_sb.sb_inopblock <= XFS_INODES_PER_CHUNK &&
!(mp->m_flags & XFS_MOUNT_IKEEP)) {
error = xfs_btree_delete(cur, &i);
if (error)
--
1.9.3
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-03-02 13:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-02 13:27 [PATCH v6 00/18] xfs: sparse inode chunks Brian Foster
2015-03-02 13:27 ` [PATCH v6 01/18] xfs: create individual inode alloc. helper Brian Foster
2015-03-02 13:27 ` Brian Foster [this message]
2015-03-02 13:27 ` [PATCH v6 03/18] xfs: support min/max agbno args in block allocator Brian Foster
2015-03-02 13:27 ` [PATCH v6 04/18] xfs: add sparse inode chunk alignment superblock field Brian Foster
2015-03-02 13:27 ` [PATCH v6 05/18] xfs: use sparse chunk alignment for min. inode allocation requirement Brian Foster
2015-03-02 13:27 ` [PATCH v6 06/18] xfs: sparse inode chunks feature helpers and mount requirements Brian Foster
2015-03-02 13:27 ` [PATCH v6 07/18] xfs: add fs geometry bit for sparse inode chunks Brian Foster
2015-03-02 13:27 ` [PATCH v6 08/18] xfs: introduce inode record hole mask " Brian Foster
2015-03-02 13:27 ` [PATCH v6 09/18] xfs: use actual inode count for sparse records in bulkstat/inumbers Brian Foster
2015-03-02 13:28 ` [PATCH v6 10/18] xfs: pass inode count through ordered icreate log item Brian Foster
2015-03-02 13:28 ` [PATCH v6 11/18] xfs: handle sparse inode chunks in icreate log recovery Brian Foster
2015-03-02 13:28 ` [PATCH v6 12/18] xfs: helper to convert holemask to inode alloc. bitmap Brian Foster
2015-03-02 13:28 ` [PATCH v6 13/18] xfs: allocate sparse inode chunks on full chunk allocation failure Brian Foster
2015-03-02 13:28 ` [PATCH v6 14/18] xfs: randomly do sparse inode allocations in DEBUG mode Brian Foster
2015-03-02 13:28 ` [PATCH v6 15/18] xfs: filter out sparse regions from individual inode allocation Brian Foster
2015-03-02 13:28 ` [PATCH v6 16/18] xfs: only free allocated regions of inode chunks Brian Foster
2015-03-02 13:28 ` [PATCH v6 17/18] xfs: skip unallocated regions of inode chunks in xfs_ifree_cluster() Brian Foster
2015-03-02 13:28 ` [PATCH v6 18/18] xfs: enable sparse inode chunks for v5 superblocks Brian Foster
2015-05-06 14:19 ` [PATCH v6 00/18] xfs: sparse inode chunks Brian Foster
2015-05-06 22:09 ` 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=1425302888-4962-3-git-send-email-bfoster@redhat.com \
--to=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