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

Существует значительный интерес к гибким дискам. Они помещают дорожки данных так близко друг к другу, что вы не сможете записать одну дорожку, не перекрыв следующую. Это может увеличить емкость примерно на 20%, но приводит к проблемам с усилением записи. В настоящее время ведется работа над файловыми системами, оптимизированными для дисков Shingled, например, см .: https://lwn.net/Articles/591782/

На некоторых гальванических дисках, таких как архив Seagate 8 ТБ, есть область кэша для случайной записи, что обеспечивает приличную производительность в обычных файловых системах. Диск может даже быть довольно быстрым при некоторых типичных рабочих нагрузках - до 200 МБ / с. Однако следует ожидать, что при переполнении кэша произвольной записи производительность может снизиться. Предположительно, некоторые файловые системы лучше избегают случайных записей в целом или шаблонов случайных записей, которые могут переполнить кэш записи, найденный на таких дисках.

Является ли основная файловая система в ядре linux лучше, если она не снижает производительность из-за разорванных дисков, чем ext4?

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

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

Я понимаю, что ST8000AS0002-1NA17Zнакопитель Seagate объемом 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

Если вы 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 для передачи каждого файла).

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