On Thu, Oct 12, 2023 at 07:05:27AM +0200, Christoph Hellwig wrote: > On Wed, Oct 11, 2023 at 11:01:16AM -0700, Darrick J. Wong wrote: > > Hi all, > > > > The realtime code uses xfs_rtblock_t and xfs_fsblock_t in a lot of > > places, and it's very confusing. Clean up all the type usage so that an > > xfs_rtblock_t is always a block within the realtime volume, an > > xfs_fileoff_t is always a file offset within a realtime metadata file, > > and an xfs_rtxnumber_t is always a rt extent within the realtime volume. > > Question as a follow up: now that we have proper types for all > the RT-specific units, what's the point of even keeping xfs_rtblock_t > around vs always using xfs_fsblock_t or xfs_rfsblock_t? The primary advantage that I can think of is code readability -- all the xfs_*rtb_ functions take xfs_rtblock_t types, and you can follow them all the way through the rt allocator/rmap/refcount code. xfs_rtblock_t is a linear quantity even with rtgroups turned on. The gross part is that one still has to know that br_startblock can be either xfs_fsblock_t or xfs_rtblock_t depending on inode and whichfork. That said, I don't think gcc actually warns about silent casts from xfs_fsblock_t to xfs_rtblock_t. --D
