VDOSTATS(8)

πŸ’– VDOSTATS πŸ’–

okay bestie, welcome to vdostats from the System Manager's Manual (section 8, she's a system manager tool, very important, very demure) πŸŽ€


✨ NAME ✨

vdostats β€” displays the configuration and statistics of VDO volumes. she's giving dashboard energy, she's giving receipts πŸ“ŠπŸ’…


✨ SYNOPSIS ✨

vdostats [options ...] [device [device ...]]

✨ DESCRIPTION ✨

so basically, vdostats shows you the configuration and statistics info for the VDO devices you name. no devices named? no problem, she'll show you info about all the VDO devices. main character behaviour honestly πŸ‘‘

🌸 tiny but crucial detail: the VDO devices have to be running for the configuration and statistics information to actually get reported. like, she can't read a vibe that isn't there, bestie.

✨ OPTIONS ✨

  • -h, --help β€” shows the help message and dips out. short, sweet, iconic 🫢
  • -a, --all β€” this one is only for backwards compatibility, no cap. it's now equivalent to --verbose.
  • --human-readable β€” displays block values in readable form (Base 2: 1 KB = 2^10 bytes = 1024 bytes). numbers that don't make your eyes water, we love to see it ✨
  • --si β€” modifies the output of the --human-readable option to use SI units (Base 10: 1 KB = 10^3 bytes = 1000 bytes). and heads up: if you didn't also pass --human-readable, this option has no effect. literally zero. she's a modifier, not a solo act πŸ’€
  • -v, --verbose β€” displays the utilization and block I/O (bios) statistics for the selected VDO devices. the full tea, the whole lore β˜•πŸ”₯
  • -V, --version β€” prints the vdostats version number and exits. flyby, no small talk πŸ¦‹

✨ OUTPUT ✨

the default output format is a table with the following columns, kinda similar to what the Linux df utility does. familiar, but make it VDO 🌈

  • Device β€” the path to the VDO volume.
  • 1K-blocks β€” the total number of 1K blocks allocated for a VDO volume (= physical volume size * block size / 1024).
  • Used β€” the total number of 1K blocks used on a VDO volume (= physical blocks used * block size / 1024).
  • Available β€” the total number of 1K blocks available on a VDO volume (= physical blocks free * block size / 1024).
  • Use% β€” the percentage of physical blocks used on a VDO volume (= used blocks / allocated blocks * 100).
  • Space Saving% β€” the percentage of physical blocks saved on a VDO volume (= [logical blocks used - physical blocks used] / logical blocks used).

✨ VERBOSE OUTPUT ✨

the --verbose option displays VDO device statistics in YAML format for the VDO devices you specified. now listen closely bestie:

the following fields will continue to be reported in future releases. but management tools should not rely upon the order in which any of the statistics are reported. order is not the vibe. the data is the vibe. periodt.

here's the whole roster πŸ’–

  • version β€” the version of these statistics.
  • release version β€” the release version of the VDO.
  • data blocks used β€” the number of physical blocks currently in use by a VDO volume to store data.
  • overhead blocks used β€” the number of physical blocks currently in use by a VDO volume to store VDO metadata.
  • logical blocks used β€” the number of logical blocks currently mapped.
  • physical blocks β€” the total number of physical blocks allocated for a VDO volume.
  • logical blocks β€” the maximum number of logical blocks that can be mapped by a VDO volume.
  • 1K-blocks β€” the total number of 1K blocks allocated for a VDO volume (= physical volume size * block size / 1024).
  • 1K-blocks used β€” the total number of 1K blocks used on a VDO volume (= physical blocks used * block size / 1024).
  • 1K-blocks available β€” the total number of 1K blocks available on a VDO volume (= physical blocks free * block size / 1024).
  • used percent β€” the percentage of physical blocks used on a VDO volume (= used blocks / allocated blocks * 100).
  • saving percent β€” the percentage of physical blocks saved on a VDO volume (= [logical blocks used - physical blocks used] / logical blocks used).
  • block map cache size β€” the size of the block map cache, in bytes.
  • write policy β€” the write policy (sync, async, or async-unsafe). this is configured via vdo modify --writePolicy=policy. πŸ‘€
  • block size β€” the block size of a VDO volume, in bytes.
  • completed recovery count β€” the number of times a VDO volume has recovered from an unclean shutdown.
  • read-only recovery count β€” the number of times a VDO volume has been recovered from read-only mode (via vdo start --forceRebuild).
  • operating mode β€” indicates whether a VDO volume is operating normally, is in recovery mode, or is in read-only mode.
  • recovery progress (%) β€” indicates online recovery progress, or N/A if the volume is not in recovery mode.
  • compressed fragments written β€” the number of compressed fragments that have been written since the VDO volume was last restarted.
  • compressed blocks written β€” the number of physical blocks of compressed data that have been written since the VDO volume was last restarted.

and now, bestie, the plot twist πŸŽ€ the remaining fields are primarily intended for software support and are subject to change in future releases β€” so management tools should not rely upon them. not their fault, they're just built different.

  • compressed fragments in packer β€” the number of compressed fragments being processed that have not yet been written.
  • slab count β€” the total number of slabs.
  • slabs opened β€” the total number of slabs from which blocks have ever been allocated.
  • slabs reopened β€” the number of times slabs have been re-opened since the VDO was started.
  • journal disk full count β€” the number of times a request could not make a recovery journal entry because the recovery journal was full.
  • journal commits requested count β€” the number of times the recovery journal requested slab journal commits.
  • journal entries batching β€” the number of journal entry writes started minus the number of journal entries written.
  • journal entries started β€” the number of journal entries which have been made in memory.
  • journal entries writing β€” the number of journal entries in submitted writes minus the number of journal entries committed to storage.
  • journal entries written β€” the total number of journal entries for which a write has been issued.
  • journal entries committed β€” the number of journal entries written to storage.
  • journal blocks batching β€” the number of journal block writes started minus the number of journal blocks written.
  • journal blocks started β€” the number of journal blocks which have been touched in memory.
  • journal blocks writing β€” the number of journal blocks written (with metadatata in active memory) minus the number of journal blocks committed.
  • journal blocks written β€” the total number of journal blocks for which a write has been issued.
  • journal blocks committed β€” the number of journal blocks written to storage.
  • slab journal disk full count β€” the number of times an on-disk slab journal was full.
  • slab journal flush count β€” the number of times an entry was added to a slab journal that was over the flush threshold.
  • slab journal blocked count β€” the number of times an entry was added to a slab journal that was over the blocking threshold.
  • slab journal blocks written β€” the number of slab journal block writes issued.
  • slab journal tail busy count β€” the number of times write requests blocked waiting for a slab journal write.
  • slab summary blocks written β€” the number of slab summary block writes issued.
  • reference blocks written β€” the number of reference block writes issued.
  • block map dirty pages β€” the number of dirty pages in the block map cache.
  • block map clean pages β€” the number of clean pages in the block map cache.
  • block map free pages β€” the number of free pages in the block map cache.
  • block map failed pages β€” the number of block map cache pages that have write errors.
  • block map incoming pages β€” the number of block map cache pages that are being read into the cache.
  • block map outgoing pages β€” the number of block map cache pages that are being written.
  • block map cache pressure β€” the number of times a free page was not available when needed.
  • block map read count β€” the total number of block map page reads.
  • block map write count β€” the total number of block map page writes.
  • block map failed reads β€” the total number of block map read errors.
  • block map failed writes β€” the total number of block map write errors.
  • block map reclaimed β€” the total number of block map pages that were reclaimed.
  • block map read outgoing β€” the total number of block map reads for pages that were being written.
  • block map found in cache β€” the total number of block map cache hits.
  • block map discard required β€” the total number of block map requests that required a page to be discarded.
  • block map wait for page β€” the total number of requests that had to wait for a page.
  • block map fetch required β€” the total number of requests that required a page fetch.
  • block map pages loaded β€” the total number of page fetches.
  • block map pages saved β€” the total number of page saves.
  • block map flush count β€” the total number of flushes issued by the block map.
  • invalid advice PBN count β€” the number of times the index returned invalid advice.
  • no space error count β€” the number of write requests which failed due to the VDO volume being out of space.
  • read only error count β€” the number of write requests which failed due to the VDO volume being in read-only mode.
  • instance β€” the VDO instance.
  • 512 byte emulation β€” indicates whether 512 byte emulation is on or off for the volume.
  • current VDO IO requests in progress β€” the number of I/O requests the VDO is current processing.
  • maximum VDO IO requests in progress β€” the maximum number of simultaneous I/O requests the VDO has processed.
  • current dedupe queries β€” the number of deduplication queries currently in flight.
  • maximum dedupe queries β€” the maximum number of in-flight deduplication queries.
  • dedupe advice valid β€” the number of times deduplication advice was correct.
  • dedupe advice stale β€” the number of times deduplication advice was incorrect.
  • dedupe advice timeouts β€” the number of times deduplication queries timed out.
  • concurrent data matches β€” the number of writes with the same data as another in-flight write.
  • concurrent hash collisions β€” the number of writes whose hash collided with an in-flight write.

🌸 and that's a wrap on this part, bestie β€” more of vdostats is coming right up, don't go anywhere πŸ’–

  • flush out β€” how many flush requests VDO sent down to the underlying storage. bye girl, go flush πŸ’…
  • write amplification ratio β€” the average number of block writes that hit the underlying storage for every single block written to the VDO device. it's giving "one in, many out" and honestly? concerning 🫢
  • bios in..., bios in partial..., bios out..., bios meta..., bios journal..., bios page cache..., bios out completed..., bios meta completed..., bios journal completed..., bios page cache completed..., bios acknowledged..., bios acknowledged partial..., bios in progress... β€” okay bestie these all count up the number of bios in each category that carry a given flag. the categories are, and stay with me:
    • bios in β€” how many block I/O requests VDO received. the receipts, incoming πŸ“₯
    • bios in partial β€” how many partial block I/O requests VDO received. only applies in 512-byte emulation mode, fyi.
    • bios out β€” how many non-metadata block I/O requests VDO sent out to the storage device.
    • bios meta β€” how many metadata block I/O requests VDO sent out to the storage device.
    • bios journal β€” how many recovery journal block I/O requests VDO sent out to the storage device.
    • bios page cache β€” how many block map I/O requests VDO sent out to the storage device.
    • bios out completed β€” how many non-metadata block I/O requests the storage device finished. slay, done ✨
    • bios meta completed β€” how many metadata block I/O requests the storage device finished.
    • bios journal completed β€” how many recovery journal block I/O requests the storage device finished.
    • bios page cache completed β€” how many block map I/O requests the storage device finished.
    • bios acknowledged β€” how many block I/O requests VDO acknowledged.
    • bios acknowledged partial β€” how many partial block I/O requests VDO acknowledged. again, 512-byte emulation mode only, no cap.
    • bios in progress β€” how many bios got submitted to the VDO and haven't been acknowledged yet. the "still cooking" pile πŸ‘‘πŸ”₯

and there are five types of flags, periodt:

  • read β€” the number of non-write bios (bios that do not have the REQ_WRITE flag set)
  • write β€” the number of write bios (bios with the REQ_WRITE flag set)
  • discard β€” the number of bios with a REQ_DISCARD flag set
  • flush β€” the number of flush bios (bios with the REQ_FLUSH flag set)
  • fua β€” the number of "force unit access" bios (bios with the REQ_FUA flag set)
lowkey important: every single bio gets counted as either a read bio or a write bio, depending on how the REQ_WRITE flag is set β€” no matter whether any of the other flags are set too. it's one or the other, always. πŸ’€
  • KVDO module bytes used β€” the current count of bytes the kernel VDO module has allocated. right now. as we speak.
  • KVDO module peak bytes used β€” the peak count of bytes the kernel VDO module has allocated since it was loaded. the high score, the record, the main character moment 🌟

🌸 EXAMPLES 🌸

here's what it looks like when you pass no options at all, bestie:

Device             1K-blocks  Used       Available   Use% Space Saving%
/dev/mapper/my_vdo 1932562432 427698104  1504864328  22%  21%

now with the --human-readable option, the block counts get converted into conventional units (that's 1 KB = 1024 bytes):

Device             Size   Used    Available   Use%   Space Saving%
/dev/mapper/my_vdo 1.8T   407.9G  1.4T        22%    21%

and with the --si option too, the block counts get reported in SI units (so 1 KB = 1000 bytes):

Device             Size   Used    Available   Use%    Space Saving%
/dev/mapper/my_vdo 2.0T   438G    1.5T        22%     21%

look at that glow-up πŸ’–


πŸŽ€ NOTES πŸŽ€

if an unprivileged user runs this command, the output may be incomplete. yeah. that's the vibe. it's giving "you didn't get the full tea because permissions said no" πŸ™ˆ


πŸ¦‹ SEE ALSO πŸ¦‹

vdo(8).


and that's the whole page, bestie!! this one came from Red Hat, dated 2020-02-18, and it's the VDOSTATS(8) manual page. go forth and read your stats, you absolute icon πŸ’œβœ¨