I guess with this in mind, I'm curious how this is different?
I guess with this in mind, I'm curious how this is different?
Maybe the latest Linux versions have lsblk versions that support these columns, but in RHEL9 at least I don't see equivalents to lsds'es WBT_LAT, QDEPTH (not the same as lsblk's RQ-SIZE), WCACHE, FUA and some others. But these 4 are which I regularly need (especially when troubleshooting a yet another slow fsync() issue etc). I did and do use lsblk all the time too, but still end up catting and grepping various additional files and correlating the results, sometimes on systems with 100+ multipath block devices.
The other reason was that I wanted a tool that shows me where it gets these values too (for myself and sometimes for explaining stuff to others).
Edit: That being said, it shouldn't be hard at all to add the said extra fields to lsblk too.
EDIT: Would also be really cool to define what each field means, if you're gonna reimplement everything anyways, why not make it as user friendly as possible.
The lsds verbose option shows where in the Linux /sys fs each individual field comes from (lsds -lpv) so that's the ultimate source of what each field means. But I could pull each sysfs file's description from docs into a table on the webpage (I'm probably too lazy to create a manpage for now - help is appreciated)
Edit: Since there are not that many fields, it would be possible to add a -d option in addition to -v to get a human readable description for each field too. One of the main sources of confusion is the "queue_depth" vs. "nr_requests" fields. My ideal (which I usually don't reach) is to make these tools "explainable", so that they tell you from where they got their input data (and what basic math was applied).