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


13

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

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

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


В настоящее время на рынке представлено 2 типа гальванических дисков. Те, кому нужна поддерживаемая ОС, например, диски HGST 10 ТБ, и те, кому не нужна поддержка конкретной ОС, например Seagate 8TB Archive. Что вы имеете в виду?
RJ-

Учитывая, что я ограничиваю FS до основных, вероятно, это будет стиль Seagate?
Gmatht

SMR, реализованный в современных накопителях, не приводит к «проблемам с усилением записи, таким как SSD». Они работают только в очень немногих способов туманно , как твердотельные накопители.
qasdfdsaq

@qasdfdsaq Я имел в виду "как с твердотельными накопителями".
Gmatht

Ответы:


4

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

Файловая система 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


Вы уверены, что эти различия характерны для SMR против PMR?
RJ-

На самом деле, нет. Я добавлю больше тестов, чтобы ответить на такие вопросы, но кто-то с большим опытом тестов мог бы справиться лучше, чем я. Надеюсь, этого достаточно, чтобы дать приблизительное представление о том, стоит ли подумать о переходе с ext4 на SMR-диск.
gmatht

3
Диски с галькой не используют копирование при записи. Они используют чтение-изменение-запись так же, как частичные записи в массивы RAID-5. Произвольные записи не замедляют работу SMR-дисков, фактически они ускоряют их. SMR-диски со скоростью 6000 об / мин в 10 раз быстрее при произвольной записи, чем не-SMR-диски со скоростью 15000 об / мин, если они помещаются в кэш, который на самом деле составляет 30 ГБ.
qasdfdsaq

@qasdfdsaq Спасибо, я удалил ссылку на CoW. Я понимаю, что на уровне диска изогнутые диски намного медленнее для случайных записей, чем PMR, но SMR может эмулировать более быстрые записи из-за кеша; диск PMR + кэш, вероятно, снова будет быстрее. У вас есть ссылка на цифру 30 ГБ? Официального номера не существует, например, в технических характеристиках Seagate. Кроме того, оптимизация для отсканированных дисков может быть проблемой, аналогичной оптимизации массивов RAID 5?
Gmatht

1
Я делал какой-то случайный поиск по теме и наткнулся на сообщение в блоге на f2fs: blog.schmorp.de/2015-10-08-smr-archive-drives-fast-now.html
Лестер Чунг

1

Если вы 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. Ваш пробег может отличаться от другого оборудования.


2
Это хороший ответ, но не на этот вопрос, поскольку он не имеет ничего общего с тем, что опубликовал оригинальный постер. Я бы посоветовал вам создать вопрос с ответом на этот вопрос. Например: «Я пытаюсь выполнить Rsync со сброшенного диска, и производительность плохая. Что я могу сделать, чтобы улучшить это? »
JakeGould
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.