Zygo
commented
4 months ago For reference, I find these notations most useful (in bees and some other tools I developed):
- hexadecimal ("0x" prefix followed by a variable number of hex digits) for device offsets, file offsets, and extent bytenrs, where it's useful to represent a page-aligned value as a round hex number.
- range notation (0xbegin..0xend) instead of a pair of start offset and length.
- no bare hex numbers. The "0x" ensures no ambiguity with a hex number that happens to contain only decimal digits.
- human-readable units for sizes and lengths (2K, 4.01MiB, etc), powers-of-2 units (KiB, MiB, etc) preferred over power-of-10 units.
- decimal for non-contiguous object identifiers (subvol/root, inode, devid). The only special numbers for those are 5 and 256, and they don't require special notation to spot.
I didn't find lengths in hex to be very useful compared to the range notation. Range notation in hex shows clearly whether the end of the range is page-aligned regardless of the start of the range. It's also more convenient when overlapping matching ends of ranges.
For device offsets I find units of 1024M with 3 fixed decimal places are useful. 1 GiB-aligned dev_extents are "xxx.001" in that notation. That's really obscure, though, and I don't know of a btrfs-progs tool that even outputs that information other than btrfs ins dump-tree.
chillenb
Do you have suggestion for the option name and format? I think there would need to be list of value categories where this applies, ie. not for inode numbers. I don't know how much flexible the format should be, we can do a preselected list of values where hex format would make sense. If this there's a need to make it more flexible (like adding exceptions for certain types) then the specifier can be enhanced.
Possible format:
--units=hex