SEARCH
diglloydTools™
Tentative: Java has Improved to the Point where a cross-platform diglloydTools DiskTester Java looks Viable
UPDATE: I have things working, but with one big unsolved issue: macOS caches writes and there is no Java API to defeat the caching. Neither does FileChannel.force() or StandardOpenFlags.DSYNC defeats this caching. As a result, on the M2 Ultra, writes go through at 50 GiB/sec until memory fills up. Gah! There might be a way around this by not using Java APIs and instead making JNA calls to POSIX file system routines, since POSIX has an F_NOCACHE flag via fcntl().
UPDATE 2: challenging... got the POSIX API working and it defeats caching as hoped, but it's not as fast and will in essence require duplicating AsynchronousFileChannel to perform more efficient I/O. It might or might not work out.
UPDATE 3: looking good, I have an impressive capability working now.
...
Previous version of Java (prior to JDK 20 or 21 not sure) could not deliver the required I/O speed. It had to do with the way buffer memory was handled between the JVM and native code.
That now looks to be fixed in JDK 20 and 21, and possibly earlier.
I was doing some preliminary testing today, to see if I could implement DiskTester in Java, a huge plus since it would be cross-platform, like IntegrityChecker Java.
Here, 39.8 GiB is being read (non-cached) at 7+ GB/sec, which is all the internal SSD of the 2023 Mac Pro can deliver:
39.8 GiB @ 6796 MiB/sec overall 6773 MiB/sec
and once cached:
39.8 GiB @ 47617 MiB/sec overall 47617 MiB/sec
Not only is the API up to the task on speed now, it handily outperforms DiskTester (the I/O methodology differs, but the cached result shows clear limits):
39.8 GiB in 6.83 seconds of read time @ 5969 MiB/sec <== uncached
39.8 GiB in 3.52 seconds of read time @ 11579 MiB/sec <== cached
