Самая быстрая файловая система Linux на Shingled дисках

Интуитивно понятные структурированные файловые системы Copy-on-Write и Log могут обеспечить более высокую производительность на гальванических дисках за счет уменьшения количества случайных записей. Эталонные тесты несколько поддерживают это, однако, эти различия в производительности не являются специфичными для разорванных дисков. Они также встречаются на необработанном диске, используемом в качестве контроля. Таким образом, переключение на диск с дисками может не иметь большого отношения к выбранной вами файловой системе.

Файловая система nilfs2 показала неплохую производительность на диске SMR. Однако это произошло потому, что я выделил весь раздел размером 8 ТБ, а тест производительности записал всего ~0,5 ТБ, поэтому очиститель nilfs не должен был запускаться. Когда я ограничил раздел до 200 ГБ, тесты nilfs даже не завершились успешно. Nilfs2 может быть хорошим выбором с точки зрения производительности, если вы действительно используете "архивный" диск в качестве архивного диска, где вы храните все данные и снимки, записанные на диск, навсегда, так как тогда очиститель nilfs не должен запускаться.

Я понимаю, что 8TB Seagate ST8000AS0002-1NA17Z диск, который я использовал для теста, имеет область кэша ~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

Если ты rsync с SMR-диска убедитесь, что файловая система смонтирована read-only или с noatime вариант.

В противном случае накопитель SMR должен будет записывать временную метку для каждого считываемого файла rsync, что приводит к значительному снижению производительности (с примерно 80 МБ / с до 3-5 МБ / с здесь) и шуму износа / щелчка головки.

Если у вас уже есть работа rsync с низкой производительностью, останавливать ее не нужно, вы можете перемонтировать исходную файловую систему

sudo mount -o remount,ro  /path/to/source/fs

Эффект будет виден не сразу, наберитесь терпения и подождите 10–20 минут, пока накопитель не закончит записывать все данные, все еще находящиеся в его буферах. Этот совет проверен и проверен в порядке.

Это может также применяться, когда rsyncвход на SMR-диск, т. е. если файловая система пытается обновить временную метку после полной записи файла на диск. Это вызывает последовательную перегрузку, и огромные полосы данных постоянно переписываются, что способствует износу дисков. Следующее может помочь:

sudo mount -t fs_type -o rw,noatime device /path/to/dest/fs

Это должно быть сделано до запуска rsync; другие факторы могут сделать эту опцию несущественной, например, небуферизованное обновление FAT/MFT, распараллеленные записи, если файловая система оптимизирована главным образом для твердотельных накопителей и т. д.

Попробуй использовать dd bs=32M а затем измените размер файловой системы на цели SMR, если вы все равно хотите сделать резервную копию полных файловых систем (в этом случае не нужно монтировать ее и запускать rsync для транспортировки каждого файла).

Фактическим используемым оборудованием был управляемый Seagate накопитель SMR 8 ТБ. Ваш пробег может отличаться от другого оборудования.