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 12:47:43 +0530 [thread overview]
Message-ID: <87v93wfx48.fsf@debian-BULLSEYE-live-builder-AMD64> (raw)
In-Reply-To: <87y28sg5e5.fsf@debian-BULLSEYE-live-builder-AMD64>
On 23 Aug 2021 at 09:48, Chandan Babu R wrote:
> 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.
I think introducing xfs_iext_max_nextents() before renaming the max extent
counter macros would reduce proliferation of XFS_IFORK_EXTCNT_MAX* macros
across the source code. If you are ok with it, I will reorder the current
patch and the next patch.
--
chandan
next prev parent reply other threads:[~2021-08-23 7:17 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-26 11:45 [PATCH V2 00/12] xfs: Extend per-inode extent counters Chandan Babu R
2021-07-26 11:45 ` [PATCH V2 01/12] xfs: Move extent count limits to xfs_format.h Chandan Babu R
2021-07-26 18:00 ` Darrick J. Wong
2021-07-27 8:07 ` Chandan Babu R
2021-07-26 11:45 ` [PATCH V2 02/12] xfs: Rename MAXEXTNUM, MAXAEXTNUM to XFS_IFORK_EXTCNT_MAXS32, XFS_IFORK_EXTCNT_MAXS16 Chandan Babu R
2021-07-27 21:56 ` Darrick J. Wong
2021-07-27 22:03 ` Darrick J. Wong
2021-07-28 3:15 ` Chandan Babu R
2021-08-23 4:18 ` Chandan Babu R
2021-08-23 7:17 ` Chandan Babu R [this message]
2021-08-23 18:16 ` Darrick J. Wong
2021-07-26 11:45 ` [PATCH V2 03/12] xfs: Introduce xfs_iext_max() helper Chandan Babu R
2021-07-27 21:58 ` Darrick J. Wong
2021-07-28 3:17 ` Chandan Babu R
2021-07-26 11:45 ` [PATCH V2 04/12] xfs: Use xfs_extnum_t instead of basic data types Chandan Babu R
2021-07-27 21:59 ` Darrick J. Wong
2021-07-28 3:38 ` Chandan Babu R
2021-07-26 11:45 ` [PATCH V2 05/12] xfs: Introduce xfs_dfork_nextents() helper Chandan Babu R
2021-07-27 22:10 ` Darrick J. Wong
2021-07-28 4:06 ` Chandan Babu R
2021-07-26 11:45 ` [PATCH V2 06/12] xfs: xfs_dfork_nextents: Return extent count via an out argument Chandan Babu R
2021-07-27 22:22 ` Darrick J. Wong
2021-07-28 4:21 ` Chandan Babu R
2021-07-26 11:45 ` [PATCH V2 07/12] xfs: Rename inode's extent counter fields based on their width Chandan Babu R
2021-07-27 22:50 ` Darrick J. Wong
2021-07-28 5:48 ` Chandan Babu R
2021-07-28 19:04 ` Darrick J. Wong
2021-07-26 11:45 ` [PATCH V2 08/12] xfs: Promote xfs_extnum_t and xfs_aextnum_t to 64 and 32-bits respectively Chandan Babu R
2021-07-27 22:29 ` Darrick J. Wong
2021-07-26 11:45 ` [PATCH V2 09/12] xfs: Rename XFS_IOC_BULKSTAT to XFS_IOC_BULKSTAT_V5 Chandan Babu R
2021-07-27 22:54 ` Darrick J. Wong
2021-07-27 23:00 ` Darrick J. Wong
2021-07-27 23:17 ` Dave Chinner
2021-07-28 6:56 ` Chandan Babu R
2021-07-26 11:45 ` [PATCH V2 10/12] xfs: Enable bulkstat ioctl to support 64-bit extent counters Chandan Babu R
2021-07-26 11:45 ` [PATCH V2 11/12] xfs: Extend per-inode extent counter widths Chandan Babu R
2021-07-27 23:09 ` Darrick J. Wong
2021-07-28 7:17 ` Chandan Babu R
2021-07-26 11:45 ` [PATCH V2 12/12] xfs: Error tag to test if v5 bulkstat skips inodes with large extent count Chandan Babu R
2021-07-27 23:10 ` Darrick J. Wong
2021-07-28 7:23 ` Chandan Babu R
2021-07-28 7:38 ` Chandan Babu R
2021-07-28 19:06 ` Darrick J. Wong
2021-07-28 21:27 ` [PATCH V2 00/12] xfs: Extend per-inode extent counters Darrick J. Wong
2021-07-29 6:40 ` Chandan Babu R
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=87v93wfx48.fsf@debian-BULLSEYE-live-builder-AMD64 \
--to=chandanrlinux@gmail.com \
--cc=djwong@kernel.org \
--cc=linux-xfs@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).