Skip to contentSkip to conversation

xfs: account for per-AG reservation in statfs f_blocks

RFC PATCH In review Darrick J. Wong 2 participants 3 messages Nov 1, 2017 XFS filesystem

lore
Share & tools
lore

Darrick J. Wong

author
#0 lore raw

RFC PATCH 1/1 xfs: account for per-AG reservation in statfs f_blocks

From: Darrick J. Wong <[email protected]>

Since the blocks reserved by the per-AG reservation mechanism are never available to userspace, there's no point in reporting them via statfs. Reduce the number of blocks reported by statfs so our space accounting works the way it did in the old days -- f_blocks is the theoretical upper bound on the amount of space that user programs could allocate, and f_blocks is the current maximum.

This eliminates the regression where you format a 100T XFS and df reports 2T are already "used". Now it reports that you have a 98T filesystem.

(Dave's thinp rfc might very well fix this whole problem; this is purely a bandaid to shut down the complaints.)

Signed-off-by Darrick J. Wong <[email protected]>
---
 fs/xfs/libxfs/xfs_ag_resv.c |    3 +++
 fs/xfs/xfs_mount.h          |    1 +
 fs/xfs/xfs_super.c          |    2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)
fs/xfs/libxfs/xfs_ag_resv.c +3 -0
index 2291f42..1c23b9f 100644
@@ -150,6 +150,7 @@ __xfs_ag_resv_free(
 	struct xfs_perag		*pag,
 	enum xfs_ag_resv_type		type)
 {
+	struct xfs_mount		*mp = pag->pag_mount;
 	struct xfs_ag_resv		*resv;
 	xfs_extlen_t			oldresv;
 	int				error;

@@ -167,6 +168,7 @@ __xfs_ag_resv_free(
 		oldresv = resv->ar_orig_reserved;
 	else
 		oldresv = resv->ar_reserved;
+	mp->m_ag_resv -= oldresv;
 	error = xfs_mod_fdblocks(pag->pag_mount, oldresv, true);
 	resv->ar_reserved = 0;
 	resv->ar_asked = 0;

@@ -217,6 +219,7 @@ __xfs_ag_resv_init(
 				pag->pag_agno);
 		return error;
 	}
+	mp->m_ag_resv += reserved;
 
 	/*
 	 * Reduce the maximum per-AG allocation length by however much we're
fs/xfs/xfs_mount.h +1 -0
index e0792d0..04ceefa 100644
@@ -152,6 +152,7 @@ typedef struct xfs_mount {
 	uint64_t		m_resblks;	/* total reserved blocks */
 	uint64_t		m_resblks_avail;/* available reserved blocks */
 	uint64_t		m_resblks_save;	/* reserved blks @ remount,ro */
+	uint64_t		m_ag_resv;	/* per-ag reserved blocks */
 	int			m_dalign;	/* stripe unit */
 	int			m_swidth;	/* stripe width */
 	int			m_sinoalign;	/* stripe unit inode alignment */
fs/xfs/xfs_super.c +1 -1
index f663022..5bfbf05 100644
@@ -1126,7 +1126,7 @@ xfs_fs_statfs(
 	spin_lock(&mp->m_sb_lock);
 	statp->f_bsize = sbp->sb_blocksize;
 	lsize = sbp->sb_logstart ? sbp->sb_logblocks : 0;
-	statp->f_blocks = sbp->sb_dblocks - lsize;
+	statp->f_blocks = sbp->sb_dblocks - lsize - mp->m_ag_resv;
 	spin_unlock(&mp->m_sb_lock);
 
 	statp->f_bfree = fdblocks - mp->m_alloc_set_aside;
#1 lore raw
Quoted 9 lines · Darrick J. Wong

From: Darrick J. Wong <[email protected]>

Since the blocks reserved by the per-AG reservation mechanism are never available to userspace, there's no point in reporting them via statfs. Reduce the number of blocks reported by statfs so our space accounting works the way it did in the old days -- f_blocks is the theoretical upper bound on the amount of space that user programs could allocate, and f_blocks is the current maximum.

Quoted 6 lines

This eliminates the regression where you format a 100T XFS and df reports 2T are already "used". Now it reports that you have a 98T filesystem.

(Dave's thinp rfc might very well fix this whole problem; this is purely a bandaid to shut down the complaints.)

Yes, it does. These two patches from the series can stand alone, though I've renamed the variables I used as a result of discussion with Brian and Amir. If you want to take these instead, I'll post my updated patches for you:

https://www.spinics.net/lists/linux-xfs/msg12211.html
https://www.spinics.net/lists/linux-xfs/msg12215.html

Cheers,

Dave.

Signature · 2 lines
Dave Chinner
[email protected]
author
#2 lore raw
Quoted 17 lines · Dave Chinner
Quoted 9 lines · Darrick J. Wong

From: Darrick J. Wong <[email protected]>

Since the blocks reserved by the per-AG reservation mechanism are never available to userspace, there's no point in reporting them via statfs. Reduce the number of blocks reported by statfs so our space accounting works the way it did in the old days -- f_blocks is the theoretical upper bound on the amount of space that user programs could allocate, and f_blocks is the current maximum.

Quoted 6 lines

This eliminates the regression where you format a 100T XFS and df reports 2T are already "used". Now it reports that you have a 98T filesystem.

(Dave's thinp rfc might very well fix this whole problem; this is purely a bandaid to shut down the complaints.)

Quoted 7 lines

Yes, it does. These two patches from the series can stand alone, though I've renamed the variables I used as a result of discussion with Brian and Amir. If you want to take these instead, I'll post my updated patches for you:

https://www.spinics.net/lists/linux-xfs/msg12211.html
https://www.spinics.net/lists/linux-xfs/msg12215.html

Sure, please send along whatever the latest version looks like.

m_LBA_size -> m_total_size -> m_fs_addr_space etc. :)

FWIW I already took the patch that converts the remaining hasFOO helper functions.

--D

Quoted 11 lines

Cheers,

Dave.

Signature · 6 lines
Dave Chinner
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html