You may have noticed that in the “vmstat -s” output there are several counters related to I/O.

...
            344270755 start I/Os
             16755196 iodones
...

Here’s what the man page has to say about these counters:

start I/Os
                   Incremented for each read or write I/O request initiated by
                   VMM. This count should equal the sum of page-ins and page-outs.

iodones
                   Incremented at the completion of each VMM I/O request.

There’s something fishy going on here. The system started roughly 34 times more I/Os than it completed. So, what gives? I had a discussion about this once in which the admin explained that I/Os get started, but not completed. The thinking goes that the I/Os get put into a queue, and if the I/O isn’t filled quickly enough it times out and retries. Sort of like a TCP retransmit for disk I/Os.

But, if that happened, you would think that there would be an error in the errpt, or errors logged in the device subsystem. At least you would see unreasonable I/O service times. And I never see anything like that.

What’s seems to be going on is that the I/O’s get dispatched to the VMM, and if they are sequential they are coalesced into 1 I/O and serviced by 1 system call. When the system detects sequential I/O, the next I/O reads in 2 * j2_minPageReadAhead file pages, the next one after that reads in 4 * j2_minPageReadAhead file pages, and so on until it reaches j2_maxPageReadAhead. Each set of I/Os is serviced by 1 system call, even though it pulls in multiple pages. And that is way better for performance.

So the ratio of start I/Os to iodones is really an indicator of how much sequential I/O the system is doing. And, if the system has lots of sequential I/O, it can be an indicator used to tune JFS2 read-ahead.

And remember, the difference between minfree and maxfree should be at least equal to j2_maxPageReadAhead. So if you make changes, adjust minfree and maxfree accordingly.

You may have noticed that in the “vmstat -s” output there are several counters related to I\/O.
\n<\/p>\n

...\n            344270755 start I\/Os\n             16755196 iodones\n...<\/code><\/pre>\n
Here’s what the man page has to say about these counters:
\n<\/p>\n
start I\/Os\n                   Incremented for each read or write I\/O request initiated by\n                   VMM. This count should equal the sum of page-ins and page-outs.\n\niodones\n                   Incremented at the completion of each VMM I\/O request.<\/code><\/pre>\n
There’s something fishy going on here. The system started roughly 34 times more I\/Os than it completed.  So, what gives? I had a discussion about this once in which the admin explained that I\/Os get started, but not completed. The thinking goes that the I\/Os get put into a queue, and if the I\/O isn’t filled quickly enough it times out and retries. Sort of like a TCP retransmit for disk I\/Os.
\n
\nBut, if that happened, you would think that there would be an error in the errpt, or errors logged in the device subsystem.  At least you would see unreasonable I\/O service times. And I never see anything like that.
\n
\nWhat’s seems to be going on is that the I\/O’s get dispatched to the VMM, and if they are sequential they are coalesced into 1 I\/O and serviced by 1 system call.  When the system detects sequential I\/O, the next I\/O reads in 2 * j2_minPageReadAhead file pages, the next one after that reads in 4 * j2_minPageReadAhead file pages, and so on until it reaches j2_maxPageReadAhead.  Each set of I\/Os is serviced by 1 system call, even though it pulls in multiple pages. And that is way better for performance.
\n
\nSo the ratio of start I\/Os to iodones is really an indicator of how much sequential I\/O the system is doing.  And, if the system has lots of sequential I\/O, it can be an indicator used to tune JFS2 read-ahead.
\n
\nAnd remember, the difference between minfree and maxfree should be at least equal to j2_maxPageReadAhead. So if you make changes, adjust minfree and maxfree accordingly.<\/p>\n","protected":false},"excerpt":{"rendered":null,"protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,1],"tags":[],"class_list":["post-598","post","type-post","status-publish","format-standard","hentry","category-aix-notes","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/posts\/598","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/comments?post=598"}],"version-history":[{"count":0,"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/posts\/598\/revisions"}],"wp:attachment":[{"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/media?parent=598"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/categories?post=598"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/tags?post=598"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}