Hi all,
Dave has periodically complained on IRC about inconsistencies in the
printk format strings for XFS tracepoints. He's right -- inodes and
block numbers are sometimes printed in decimal and other times in hex.
Worse yet, the tags associated with the names are also inconsistent and
aren't clear about the units of the numbers reported. Most "blocks" and
"length" fields are fs blocks, but some are daddrs, some are byte
counts, etc.
Sooo... here's a disruptive bikeshed-attractor patchset that changes all
those numbers to hexadecimal and tries to make the naming consistent.
Or at least more consistent than they are now.
Here's the cleaned up nomenclature, starting with the ones that were
already in use:
ino: filesystem inode number
agino: per-AG inode number
agno: allocation group number
agbno: per-AG block number in fs blocks
owner: reverse-mapping owner, usually inodes
daddr: physical block number in 512b blocks
startblock: physical block number for file mappings. This is either a
segmented fsblock for data device mappings, or a rfsblock
for realtime device mappings
fileoff: file offset, in fs blocks
pos: file offset, in bytes
forkoff: inode fork offset, in bytes
icount: number of inode records
disize: ondisk file size, in bytes
isize: incore file size, in bytes
And here are three new tags:
blockcount: number of blocks in an extent, in fs blocks
daddrcount: number of blocks in a physical extent, in 512b blocks
bytecount: number of bytes
If you're going to start using this mess, you probably ought to just
pull from my git trees, which are linked below.
This is an extraordinary way to destroy everything. Enjoy!
Comments and questions are, as always, welcome.
--D
kernel git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=standardize-tracepoints-5.15
---
fs/xfs/libxfs/xfs_types.h | 5 +
fs/xfs/scrub/trace.h | 74 ++++++++++----------
fs/xfs/xfs_trace.h | 169 ++++++++++++++++++++++-----------------------
3 files changed, 127 insertions(+), 121 deletions(-)
