On Tue, Jun 21, 2022 at 05:23:46PM -0500, Eric Sandeen wrote: > On 6/21/22 1:50 AM, Chandan Babu R wrote: > > xfs_extnum_t is the type to use to declare variables whose values have been > > obtained from per-inode extent counters. This commit replaces using basic > > types (e.g. uint64_t) with xfs_extnum_t when declaring such variables. > > > > Signed-off-by: Chandan Babu R <chandan.babu@xxxxxxxxxx> > > --- > > Thanks Chandan - I had rolled something like this into the merge of kernel > "xfs: Use xfs_extnum_t instead of basic data types" > because it seemed like it should maybe all be done at once. > > And the tree Dave has already had (some of) these type changes in db/ and > repair/dinode.c as part of that patch. > > On top of that, I added a lot more of these conversions, i.e. to > bmap(), bmap_one_extent(), and make_bbmap() in db/bmap.c, > process_bmbt_reclist() in db/check.c, fa_cfileoffd() and > fa_dfiloffd() in db/faddr.c ... perhaps I should send you my net diff > on top of the tree dchinner assembled, and you can see what you think? Just merge what we've already got, then do an audit to check for anything that is missing and then commit them. > But at the highest level, does it make more sense to convert everything > in the utilities at the same time as "xfs: Use xfs_extnum_t instead of > basic data types" is applied to xfsprogs libxfs/ or would separate patches > be better? So long as it is converted before the release point it doesn't matter. We don't have extent counts of > 2*32 out in the wild yet, so as long as the conversions are all sorted by the time 5.19 is done then it just doesn't matter how many commits it takes because users won't be using the dev tree to repair filesystems with extent counts that could overflow a 32 bit counter.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
