Интуитивно понятные структурированные файловые системы «Копировать при записи» и «Журнал» могут обеспечить более высокую производительность на гальванических дисках за счет уменьшения количества случайных записей. Эталонные тесты несколько поддерживают это, однако, эти различия в производительности не являются специфичными для гальванических дисков. Они также встречаются на необработанном диске, используемом в качестве контроля. Таким образом, переключение на гальванический диск может не иметь большого значения для вашего выбора файловой системы.
Файловая система nilfs2 показала неплохую производительность на диске SMR. Однако это произошло потому, что я выделил весь раздел размером 8 ТБ, а тест производительности записал всего ~ 0,5 ТБ, поэтому очиститель nilfs не должен был запускаться. Когда я ограничил раздел до 200 ГБ, тесты nilfs даже не завершились успешно. Nilfs2 может быть хорошим выбором с точки зрения производительности, если вы действительно используете "архивный" диск в качестве архивного диска, где вы храните все данные и снимки, записанные на диск, навсегда, так как тогда очиститель nilfs не должен запускаться.
Я понимаю, что накопитель ST8000AS0002-1NA17Z объемом 8 ТБ, который я использовал для теста, имеет область кэша ~ 20 ГБ . Я изменил настройки файлового сервера filebench по умолчанию так, чтобы набор эталонных тестов составлял ~ 125 ГБ, больше, чем область кеша без оболочки:
set $meanfilesize=1310720
set $nfiles=100000
run 36000
Теперь для фактических данных. Количество операций измеряет "общую" производительность файлового сервера, в то время как ms/op измеряет задержку случайного добавления и может использоваться в качестве приблизительного ориентира для выполнения случайной записи.
$ grep rand *0.out | sed s/.0.out:/\ / |sed 's/ - /-/g' | column -t
SMR8TB.nilfs appendfilerand1 292176ops 8ops/s 0.1mb/s 1575.7ms/op 95884us/op-cpu [0ms - 7169ms]
SMR.btrfs appendfilerand1 214418ops 6ops/s 0.0mb/s 1780.7ms/op 47361us/op-cpu [0ms-20242ms]
SMR.ext4 appendfilerand1 172668ops 5ops/s 0.0mb/s 1328.6ms/op 25836us/op-cpu [0ms-31373ms]
SMR.xfs appendfilerand1 149254ops 4ops/s 0.0mb/s 669.9ms/op 19367us/op-cpu [0ms-19994ms]
Toshiba.btrfs appendfilerand1 634755ops 18ops/s 0.1mb/s 652.5ms/op 62758us/op-cpu [0ms-5219ms]
Toshiba.ext4 appendfilerand1 466044ops 13ops/s 0.1mb/s 270.6ms/op 23689us/op-cpu [0ms-4239ms]
Toshiba.xfs appendfilerand1 368670ops 10ops/s 0.1mb/s 195.6ms/op 19084us/op-cpu [0ms-2994ms]
Поскольку Seagate - 5980 об / мин, можно наивно ожидать, что Toshiba будет на 20% быстрее. Эти тесты показывают, что он примерно в 3 раза (200%) быстрее, поэтому эти тесты бьют по снижению производительности. Мы видим, что диск Shingled (SMR) по-прежнему не может сравниться с производительностью ext4 на диске без оболочки (PMR). Наилучшая производительность была у nilfs2 с разделом 8 ТБ (поэтому очистителю не нужно было работать), но даже тогда он был значительно медленнее, чем у Toshiba с ext4.
Чтобы сделать вышеприведенные тесты более понятными, это может помочь нормализовать их относительно производительности ext4 на каждом диске:
ops randappend
SMR.btrfs: 1.24 0.74
SMR.ext4: 1 1
SMR.xfs: 0.86 1.98
Toshiba.btrfs: 1.36 0.41
Toshiba.ext4: 1 1
Toshiba.xfs: 0.79 1.38
Мы видим, что на SMR-диске btrfs имеет большинство преимуществ в общем количестве операций, которые он имеет на ext4, но штраф за случайное добавление не так драматичен, как соотношение. Это может привести к переходу на btrfs на диске SMR. С другой стороны, если вам нужны случайные добавления с низкой задержкой, этот тест предполагает, что вы хотите использовать xfs, особенно для SMR. Мы видим, что хотя SMR/PMR могут влиять на выбор файловой системы, более важной представляется рабочая нагрузка, для которой вы оптимизируете.
Я также провел тест на чердаке. Продолжительность запусков на чердаке (на полных дисковых разделах 8TB SMR) была:
ext4: 1 days 1 hours 19 minutes 54.69 seconds
btrfs: 1 days 40 minutes 8.93 seconds
nilfs: 22 hours 12 minutes 26.89 seconds
В каждом случае хранилища на чердаке имели следующие характеристики:
Original size Compressed size Deduplicated size
This archive: 1.00 TB 639.69 GB 515.84 GB
All archives: 901.92 GB 639.69 GB 515.84 GB
Добавление второй копии того же диска объемом 1 ТБ на чердак заняло 4,5 часа в каждой из этих трех файловых систем. Необработанный дамп тестов и информации о smartctl находится по адресу:http://pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmarks/SMR.
