“Blocks” are units of storage for datasets as well. The nomenclature can get confusing.
Think of “recordsize” as the policy for the maximum size that a block can be.
Think of a “block” as the actual data itself as seen in RAM.
Think of the “block-on-disk” as the form (and size) of the block as stored on the physical storage medium.
Some examples:
If your dataset’s “recordsize” policy is 1M, and you save a non-compressible 8K file, then it will be comprised of a single block that is 8K in size. It will be 8K in RAM when used by applications, and 8K stored on disk.
If your dataset’s “recordsize” policy is 1M, and you save a non-compressible 980K file, then it will be comprised of a single block that is 1M (next power-of-two) in size. It will be 1M in RAM when used by applications, and 980K stored on disk (or 1M stored on disk if you’re not using any inline compression).
If your dataset’s “recordsize” policy is 1M, and you save a highly-compressible 980K file, then it will be comprised of a single block that is 1M (next power-of-two) in size. It will be 1M in RAM when used by applications, and perhaps 160K stored on disk. (Again, assuming inline compression is enabled.)
If your dataset’s “recordsize” policy is 1M, and you save a non-compressible 4.5M file, then it will be comprised of a fives block that are 1M each in size. All blocks will be1M in RAM when used by applications, and 1M each stored on disk, except for the last block which will only be 512K if you’ve enabled any form of inline compression.
For any scenario above, whenever you do a true in-place modification, the entire block (as seen in RAM) must be read and then re-written. Consider the last example: Modifying in-place just a few KB in the middle of the file will require reading and re-writing 1MB worth of data.
Enabling even ZLE inline compression (at minimum) will removing any “padding” at the end of a file’s last block. (ZLE is insanely fast, and compresses a sequence of zero’s into nothing.) Therefore, the last block of a file might only be a few KB, while the remainder is “padding of zeros” up to the 1M recordsize policy. On the storage disk itself, this block only physically consumes a few KB, since any form of inline compression makes this padding a non-issue.