Из того, что вы упомянули о сжатии, я предполагаю, что все размеры / скорости хранения, которые вы описали, были в несжатом размере. В противном случае это может увеличить время передачи на коэффициент, равный вашему среднему коэффициенту сжатия (но не в том случае, если доступ к диску является узким местом, поскольку распаковка / сжатие происходит после чтения с диска zfs sendи перед записью на диск zfs receive).
Судя по собранной вами информации, похоже, что вы ограничены пропускной способностью диска, а не сетевым подключением. Вы упомянули, что каждая система может выполнять чтение / запись со скоростью ~ 500 МБ / с, поэтому лучшее время передачи для 35 ТБ составляет около 20 часов (примерно в 2,5 раза медленнее, чем просто передача по сети 10 Гбит / с). Но, основываясь на вашей настройке зеркалирования, я удивлен, что чтение и запись будут иметь одинаковую пропускную способность - вы уверены в этом? В отправляющей системе вам нужно только читать с одного диска (чтобы вы могли распараллеливать чтение на трех дисках), но в принимающей системе вы должны записывать на все три диска (так что вы ограничены пропускной способностью самого медленного диска в в любое время). Чтобы проверить пропускную способность записи на принимающей стороне, вы можете запустить dd if=/dev/urandom of=some_file_in_pool bs=1M count=1024 conv=fdatasync.
Поскольку вы сказали, что принимающие диски заняты на 100%, я предполагаю, что они не достигают пропускной способности записи 500 МБ / с. Это может быть связано либо с тем, что реальный лимит записи ниже этого ( ddкоманда, приведенная выше, должна подтвердить), либо с тем, что системе приходится выполнять чтение метаданных во время приема, и это нарушает вашу приятную рабочую нагрузку при записи большого размера IO добавив кучу дисков ищет в миксе. Вы должны быть в состоянии исследовать вторую гипотезу более глубоко, используя DTrace, чтобы увидеть, как ioпоставщик считает ваши размеры чтения / записи.