Я заметил, что мои резервные копии были очень медленными, поэтому я провел тест скорости с помощью sysbench следующим образом:
$ mkdir benchmark
$ cd benchmark
$ sysbench fileio prepare
$ sysbench fileio --file-test-mode=rndrw run
Вот результаты:
sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Extra file open flags: 0
128 files, 16MiB each
2GiB total file size
Block size 16KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...
Threads started!
File operations:
reads/s: 72.23
writes/s: 48.16
fsyncs/s: 153.46
Throughput:
read, MiB/s: 1.13
written, MiB/s: 0.75
General statistics:
total time: 10.0039s
total number of events: 2741
Latency (ms):
min: 0.03
avg: 3.65
max: 86.83
95th percentile: 12.30
sum: 9991.70
Threads fairness:
events (avg/stddev): 2741.0000/0.00
execution time (avg/stddev): 9.9917/0.00
Жесткий диск представляет собой новый 4 ТБ Western Digital в футляре Nisuta USB 3.
На диске пуст только раздел EXT4.
Почему так медленно?
Я помню, что видел что-то о низкой производительности дисков Seagate 4 ТБ, особенно на машинах с Linux. У меня есть один из них, и это собака, когда вы начинаете копировать много файлов. Ждал несколько часов, пока он скопирует около 60 ГБ файлов.
Я прочитал об этом через некоторое время после того, как получил диск, и понял это. Насколько я знаю, внешний 4 ТБ. У меня есть технология SMR с кэш-памятью, которая помогает скрыть проблемы с производительностью. Но как только вы пишете интенсивные задачи, такие как попытка скопировать несколько больших файлов одновременно, вы замечаете радикальное падение производительности. Я вижу, что каждая копия падает до 500 КБ/с. Общая комбинированная скорость передачи между всеми копиями медленнее, чем мое интернет-соединение.
Вот хорошее объяснение SMR, которое я нашел, когда впервые попытался понять, что происходит:
https://blocksandfiles.com/2020/04/15/seagate-2-4-and-8tb-barracuda-and -desktop-hdd-smr/
Почему SMR-накопители неоптимальны для рабочих нагрузок с интенсивными операциями записи
Гоночная магнитная запись передает больше данных на пластины диска за счет частичного >перекрытия дорожек записи, оставляя дорожку чтения внутри них чистой. Скорость чтения > ввода-вывода не изменяется, но перезапись данных требует, чтобы блоки дорожек были > прочитаны, отредактированы с новыми данными и перезаписаны как новый блок. Это существенно увеличивает время перезаписи данных по сравнению с >дисками с обычной записью.
Задержки SMR больше влияют на рабочие нагрузки с интенсивным чтением, чем на рабочие нагрузки с интенсивным чтением. Поэтому диски SMR обычно используются >для приложений архивного типа, а не для смешанных сценариев использования в режиме реального времени или интенсивного использования маршрутов.
Кэширование операций записи в незащищенную зону диска и запись их >в защищенные сектора во время простоя >эффективно скроет медленную скорость перезаписи — до тех пор, пока кэш не заполнится, когда запросы на перезаписи все еще >поступают.
Затем кеш сбрасывается, и все данные записываются в защищенную область > диска, вызывая паузу в несколько секунд, пока это > делается.
Вы также можете заглянуть на форумы Mac. Я тоже на Ubuntu, но мы все в одной лодке.
https://hardforum.com/threads/seagate-3tb-slow-write-speeds-drive-failing.1924143/