Re: [PATCH V2 02/12] xfs: Rename MAXEXTNUM, MAXAEXTNUM to XFS_IFORK_EXTCNT_MAXS32, XFS_IFORK_EXTCNT_MAXS16

From: Chandan Babu R <chandanrlinux@gmail.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH V2 02/12] xfs: Rename MAXEXTNUM, MAXAEXTNUM to XFS_IFORK_EXTCNT_MAXS32, XFS_IFORK_EXTCNT_MAXS16
Date: Mon, 23 Aug 2021 09:48:58 +0530	[thread overview]
Message-ID: <87y28sg5e5.fsf@debian-BULLSEYE-live-builder-AMD64> (raw)
In-Reply-To: <87eebjw2lj.fsf@garuda>

On 28 Jul 2021 at 08:45, Chandan Babu R wrote:
> On 28 Jul 2021 at 03:33, Darrick J. Wong wrote:
>> On Tue, Jul 27, 2021 at 02:56:11PM -0700, Darrick J. Wong wrote:
>>> On Mon, Jul 26, 2021 at 05:15:31PM +0530, Chandan Babu R wrote:
>>> > In preparation for introducing larger extent count limits, this commit renames
>>> > existing extent count limits based on their signedness and width.
>>> > 
>>> > Signed-off-by: Chandan Babu R <chandanrlinux@gmail.com>
>>> > ---
>>> >  fs/xfs/libxfs/xfs_bmap.c       | 4 ++--
>>> >  fs/xfs/libxfs/xfs_format.h     | 8 ++++----
>>> >  fs/xfs/libxfs/xfs_inode_buf.c  | 4 ++--
>>> >  fs/xfs/libxfs/xfs_inode_fork.c | 3 ++-
>>> >  fs/xfs/scrub/inode_repair.c    | 2 +-
>>> >  5 files changed, 11 insertions(+), 10 deletions(-)
>>> > 
>>> > diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
>>> > index f3c9a0ebb0a5..8f262405a5b5 100644
>>> > --- a/fs/xfs/libxfs/xfs_bmap.c
>>> > +++ b/fs/xfs/libxfs/xfs_bmap.c
>>> > @@ -76,10 +76,10 @@ xfs_bmap_compute_maxlevels(
>>> >  	 * available.
>>> >  	 */
>>> >  	if (whichfork == XFS_DATA_FORK) {
>>> > -		maxleafents = MAXEXTNUM;
>>> > +		maxleafents = XFS_IFORK_EXTCNT_MAXS32;
>>> 
>>> I'm not in love with these names, since they tell me roughly about the
>>> size of the constant (which I could glean from the definition) but less
>>> about when I would expect to find them.  How about:
>>> 
>>> #define XFS_MAX_DFORK_NEXTENTS    ((xfs_extnum_t) 0x7FFFFFFF)
>>> #define XFS_MAX_AFORK_NEXTENTS    ((xfs_aextnum_t)0x00007FFF)
>>
>> Or, given that 'DFORK' already means 'ondisk fork', how about:
>>
>> XFS_MAX_DATA_NEXTENTS
>> XFS_MAX_ATTR_NEXTENTS
>
> Yes, I agree. These names are better. I will incorporate your suggestions
> before posting V3.
>

Using XFS_MAX_[ATTR|DATA]_NEXTENTS won't be feasible later in the patch series
since the maximum extent count for the two inode forks depend on whether
XFS_SB_FEAT_INCOMPAT_NREXT64 feature bit is set or not. With the incompat
feature bit set, extent counts for attr and data forks can have maximum values
of (2^32 - 1) and (2^48 - 1) respectively. With the incompat feature bit not
set, extent counts for attr and data forks can have maximum values of (2^15 -
1) and (2^31 - 1) respectively.

Also, xfs_iext_max_nextents() (an inline function introduced in the next patch
in this series) abstracts away the logic of determining the maximum extent
count for an inode fork.

-- 
chandan