Is there a simple test to validate if disk speed is acceptable in relation to database I/O operations?

Is there a simple test to validate if disk speed is acceptable in relation to database I/O operations?

There is no single simple test that will tell if the disk performance is acceptable as there are many variables that may impact the DB performance.

However, a widely accepted method by Progress DBAs and consultants alike is the "Furgal Test".
It is another use-case for the BIGROW command, used to measure disk speed specifically by timing how long it takes to grow a bi file of a certain size on disk.

This benchmark provides a quick and easy means to uniformly gather information about synchronous I/O performance. The results enable:

• Comparative BIGROW performance results with other environments when investigating bottlenecks on I/O or CPU that are impacting our ability to write changes to disk in a timely fashion. For example when Checkpoint metrics show Sync Time as a fair proportion of the Checkpoint Duration timings.
• A litmus test of sorts. While bigrow is sequential and database I/O is completely random, experience has shown a strong correlation between long bigrow times and poor application/database performance.
• To keep an eye on infrastructure trends that influence OpenEdge performance. This (historic or environment comparative) evidence provides a reliable indicator of storage implementation and/or configuration issues which lead back to database/application performance problems.

In order to execute this unbuffered I/O test use the undocumented parameter: -zextendSyncIO.
This parameter is not ever expected to be needed otherwise unless bigrow is being used as a benchmark on platforms running an OpenEdge version with disk I/O performance improvements.

Example:

Re-format 96 MB disk space to pre-allocate 6 bi clusters

A BIGROW benchmark widely accepted over the years and across many different storage systems is that it should take no longer than 10 seconds to write a 100 MB BI file.
To verify a minimum of 10 MB/Second sequential write speed measured using a BIGROW benchmark
Add the 4 default bi clusters to the bi grow value specified, to pre-grow the required number of bi clusters

UNIX: 16 MB bi cluster size with 1024 16 KB bi blocks
 

proutil <dbname> -C truncate bi -bi 16384 -biblocksize 16
time -p proutil <dbname> -C bigrow 2 -zextendSyncIO

Windows: 16 MB bi cluster size with 2048 8 KB bi blocks
 

proutil <dbname> -C truncate bi -bi 16384 -biblocksize 8
timer.bat "proutil <dbname> -C bigrow 2 -zextendSyncIO

Timer.bat

REM: timer.bat to fake UNIX 'time'
@echo off
echo %time% < nul
cmd /c %1
echo %time% < nul

When sequential write speed is not optimal and other OS metrics refute results, other tools outside of Progress will provide supporting evidence.
One use-case example is recorded in Article  The "proutil bigrow"command performs differently between 2 different disks types

This tests before-image log write performance.
it correlates well with performance (i.e. poor result is a predictor of poor performance) but it isn't the whole story.
Just as important is random read/write speed for data extents.
Whether disk bandwidth is sufficient is highly dependent on the application, the number of users, database configuration parameter settings, kernel settings, the overall workload, and other factors.
There is no simple "rule-of-thumb" that will suit everyone.