compiled blocklet for disk io

[vivien]

compiled blocklet for disk io

[kb100]

https://github.com/vivien/i3blocks-contrib/wiki/Oneliners#disk-io

Actually there is a one-liner in the wiki for this.

[zetok]

Actually there is a one-liner in the wiki for this.

Actually, there isn't ;)

One-liner prints MB/s, while my disk_io prints KB/s or MB/s, depending on whether there has been enough bytes read/written to pass the magical barrier of 2^20 bytes.

Also, from what I understand (don't really know awk) the one-liner seems to be summing up all values from columns provided by iostat, which will ~falsify the resulting product if you want disk usage only of your "real", physical devices. I.e. if you're using device mapper enjoy never knowing how much data has been actually read/written :3

In other words, yes

At first I've tried to do the same via script/tool, but it appeared to me that my script-fu is not strong enough, and there are no tools that would do the job.

there are things that ~almost do the job, but don't do it well enough. And improving that one-liner in a way that would do the job is beyond of what I'm able to do.

Edit: actually, it's worse than I thought – that one-liner doesn't work at all, if you're interested in even "smallest" reads/writes - e.g. if 500 KB has been written in 1s out of 5s, the one-liner will go 'lol nope' route, and claim that there has been no data read/written during those 5s.

Lowering the time interval doesn't help – i.e. even with iostat -dmz 1 you don't have the info on smallest read/writes. + the false data, given that device mapper is being used.

[kb100]

:( many of the things you point out as flaws I put in purposefully because the blocklet annoyed me. Mainly, I didn't like to see it constantly switching between KB/s to MB/s or otherwise doing anything that will make the blocklet change length (thus disturbing all my other blocklets). In the wiki the script uses 1 decimal point of accuracy, so the threshold is more like 105KB, not 1MB, (though I personally leave it at a 1MB threshold because I thought 1 decimal point of accuracy was annoying.)

As for "real" devices, you are correct. If you want to tell the script which devices to look at, simply replace else with else if ($1 ~ /sda1|sda2/) e.g. if you wanted sda1 and sda2. Perhaps I should add a comment about these things in the wiki as not everyone has the necessary script-fu.

FYI, It seems that your script counts up everything starting with "sd". This will miss hard drives like hda, will include anything starting with sd that isn't a real device, and it will double count RAID1 arrays whereby bytes written to the fs gets written to multiple physical disks.

It seems we want very different things from the disk io blocklet (which is okay!). I am much more concerned with getting a feel for the magnitude of the io to tell me whether everything is ok or whether I need to fix something; my brain doesn't distinguish much between 200KB/s and 500KB/s (for disk io, that is, different story for network). You seem to want the blocklet to be more accurate at the cost of (what I would call) more distraction.

I recognize I may be in the minority on what the desired behavior is. I am contemplating a few options.

My first choice would be to upgrade the disk io oneliner to a full script, similar to what was done with https://github.com/vivien/i3blocks-contrib/tree/master/bandwidth, offering many different configuration options. (Perhaps you would like to help in this endeavor?) The only thing I don't see how to fix yet is how to automatically tell which devices are "real", perhaps something like

    lsblk -s --ascii | grep -v "^[\` |]"

[kb100]

As for linking your script, that is definitely another option I am considering (hopefully other contributors will comment).

[zetok]

As for "real" devices, you are correct. If you want to tell the script which devices to look at, simply replace else with else if ($1 ~ /sda1|sda2/) e.g. if you wanted sda1 and sda2.

Right, though it would seem like this approach is a bit inflexible? I.e. it would require "hardcoding" which devices should be "monitored" for IO..? Anything more would require using regexp..?

FYI, It seems that your script counts up everything starting with "sd".

Actually, regexp catched \ssd[a-zA-Z]+ – [whitespace][s][d][any alphabet letter repeated once or more times].

This will miss hard drives like hda, will include anything starting with sd that isn't a real device (…)

About supporting hda - in the years of using Linux I have never encountered anything using that naming scheme, so I figured that there's no point in supporting something that is in practice not used.

And there's a bug that I didn't catch earlier, since regexp also did include partitions :/
Thanks, fixed :)

(…) and it will double count RAID1 arrays whereby bytes written to the fs gets written to multiple physical disks.

Actually, since I'm interested in getting real numbers on how many bytes were written to all "real" disks, I don't really care about ~RAID1. I.e. I do want to know that there's ~200MB/s written to devices when I'm writing a 100MB file to FS on RAID1.
In other words, I don't care about FS, but about "raw" bytes written to "real" devices.

It seems we want very different things from the disk io blocklet (which is okay!). I am much more concerned with getting a feel for the magnitude of the io to tell me whether everything is ok or whether I need to fix something; (…)

Yeah, kinda different things :)
While you're interested mostly in magnitude, I'm more interested in whether there's any work done at all - i.e. I really want to know whether disks are as idle as they're supposed to be, and that nothing is eating away my disk's life at constant rate of 64 KB/s ;)

And if there is some activity going on, only then I'm somewhat interested in magnitude. :)

Mainly, I didn't like to see it constantly switching between KB/s to MB/s or otherwise doing anything that will make the blocklet change length (thus disturbing all my other blocklets).
(…)
You seem to want the blocklet to be more accurate at the cost of (what I would call) more distraction.

Well, the "solution" to that might be min_width=i/o: 100.1M 100.1M, which I don't use, since I don't have enough space on my i3bar left for it to work without pushing other blocklet out of sight. :/
Perhaps I should add it to readme?

---

Edit: forgot to reply to last part of comment

My first choice would be to upgrade the disk io oneliner to a full script, similar to what was done with https://github.com/vivien/i3blocks-contrib/tree/master/bandwidth, offering many different configuration options. (Perhaps you would like to help in this endeavor?)

Sorry, I cannot really into scripts. Most of what I'm able to do are ~simple bash wrappers around things, and if I need something more complex, I resort to writing it in Rust. As they say, when you have a hammer everything looks like a nail ;)

The only thing I don't see how to fix yet is how to automatically tell which devices are "real" (…)

Is it easy to make "not real" device to be named sdX and be listed in /proc/diskstats ?

[kb100]

About supporting hda - in the years of using Linux I have never encountered anything using that naming scheme, so I figured that there's no point in supporting something that is in practice not used.

I encourage you to search for 'hda' in https://www.kernel.org/doc/Documentation/iostats.txt which you link to from your own source code. ;)

[zetok]

I encourage you to search for 'hda' in https://www.kernel.org/doc/Documentation/iostats.txt which you link to from your own source code. ;)

Um..

(…) that is in practice not used.

Documentation ≠ actually being used.