Same backing storage, same mount sizes. The extra volume added a hop and 16 percent.
Saves were already slow, so a write buffer or cache volume was added in front of the archive storage. Saves got slower still.
Nobody can explain why, because on paper a cache should only help, and the purchase order said it would.
The buffer volume sat on the same backing storage as the archive itself. Every write now crossed two mounts instead of one, and both carried the same 64 KB read and write sizes.
Measured with the service log timing pairs, the extra hop made saves 16 percent worse. The underlying cause, the mount sizes, had not been touched.
Remove the buffer volume. Fix the read and write sizes on the storage class instead, which is where the time was going all along.
Before any storage purchase, run a batch of a hundred or more documents through the real path and read the timing pairs. If the numbers do not move, the purchase will not either.
+16%slower with the buffer volume in place, on the same backing storage
What the logs said
timings save p50 up 16% after buffer volume introduced system report buffer volume and archive volume on the same backing store, both 64 KB rsize/wsize verdict failure mode ONE: an extra hop on an already misconfigured path fix remove the volume, fix the mount sizes, retest with a 100-document batch