On Mon, Jul 19, 2021 at 09:56:00AM -0700, Darrick J. Wong wrote: > Linus previously complained to me about filesystem code (especially > iomap since it was "newer") (ab)using loff_t variables to store the > lengths of byte ranges. It was "loff_t length;" (or so willy > recollects) that tripped him up. > > ISTR he also said we should use size_t for all lengths because nobody > should do operations larger than ~2G, but I reject that because iomap > has users that iterate large ranges of data without generating any IO > (e.g. fiemap, seek, swapfile activation). > > So... rather than confusing things even more by mixing u64 and ssize_t > for lengths, can we introduce a new 64-bit length typedef for iomap? > Last summer, Dave suggested[1] something like: > > typedef long long lsize_t; > > That would enable cleanup of all the count/size/length parameters in > fs/remap_range.c and fs/xfs/xfs_reflink.c to use the new 64-bit length > type, since those operations have never been limited to 32-bit sizes. I'd rather avoid playing guinea pig for a somewhat odd new type. For now I've switched it to the loff_t as that matches the rest of iomap. If we switch away either to a new type or s64/u64 we should probably do it as a big sweep.
