diglloydTools IntegrityChecker Java: Optimizing Performance on Hard Drives (macOS)

re: data integrity and diglloydTools and IntegrityChecker Java
re: diglloydTools IntegrityChecker Java: Optimizing Performance on Hard Drives
re: Optimizing Performance by Working Around macOS Caching Performance Bugs

Optimal thread and buffer configurations are wildly different for optimal performance on an SSD versus a hard drive. Worse, macOS also has a sporadic 30.000 second hang bug on hard drives with too many I/O requests outstanding.

While IntegrityChecker Java (icj) optimizes its threads and buffers to the extent it can, a reliable way to always detect the type of volume (hard drive or SSD or RAID, etc) is not available.

Seeing the info for a volume

On macOS, use 'diskutil' to view information on whether a volume is an SSD or hard drive.

diskutil info "volumeName"

IntegrityChecker Java queries this information, but it is sometimes unavailable. Examples include RAID volumes, external enclosures that do not convey the drive info, etc.

Optimizing IntegrityChecker Java for hard drives

If the volume information is available, all is well. Otherwise, icj defaults to SSD optimizations. But optimizing for SSD results in significantly impaired performance for hard drives, up to 40% slower.

Also, more outstanding I/O requests on hard drives can sporadically trigger a macOS file system bug that stalls all I/O for 30.000 seconds (icj warns when this happens and resumes execution). Yes, years later after Tim Cook’s promises about a focus on software quality, macOS Big Sur still has many bugs in it.

For icj update or icj verify on a hard-drive-based volume lacking that info as per above, insert the --optimize option like this:

# 'target' is a volume or folder, etc (or more than one).
icj update --optimize HDD target
icj verify --optimize HDD target