Почему mdadm пишет неприменимо медленный при синхронном монтировании?

Производительность существенно хуже, потому что синхронная запись вынуждает вычисление четности ковать диски.

В целом вычисления и запись четности являются относительно медленным процессом, особенно с RAID 6 - в Вашем случае, мало того, что md должен фрагментировать данные в четыре блока, это затем вычисляет два блока четности для каждой дорожки. Для улучшения производительности Реализации RAID (включая md) будут кэшировать недавно используемые дорожки в памяти для сравнения данных, которые будут записаны с существующими данными и быстро повторно вычислят четность на записи. Если новые данные записаны в кэшируемую дорожку, они могут сравнить, фрагментировать, и повторно вычислить четность, никогда не касаясь диска, то сбросить его позже. Вы создали ситуацию, где md всегда пропускает кэш, в этом случае это должно считать дорожку из диска, сравнить данные, фрагментировать новые данные, повторно вычислить четность, затем сбросить новую дорожку непосредственно к диску. Что потребовало бы, чтобы нулевые чтения и записи из/в диск на удачном обращении в кэш стали шестью чтениями и шестью записями для каждой записанной дорожки.

Предоставленный, разница в производительности, которую Вы наблюдали, огромна (1.9GB/s по сравнению с 449KB/s), но я думаю, что это все составляется в том, сколько работы md делает для поддержания целостности данных.

Этот хит производительности может быть составлен тем, как Вам расположили диски..., если у Вас будут они все на одном контроллере, то так много дополнительного чтения и записи приведут производительность в бездействие.

Можно ли сказать нам, как 6 дисков составлены? Звуки мне, как будто они были частью SAN/DAS безотносительно целей - которые propably состоят из тех же физических дисков (поэтому, если все 6 находятся на том же диске, это ухудшит производительность по сравнению с отдельным диском 6).

Взгляните на эту ссылку на anwerleaks.com.

Таким образом, как Вы настраивали свой битовый массив?

Цитата вопрошающего:

Но есть еще кеширование Linux:

 root @ ubuntu : / mnt / raid6 # dd if = / dev / zero of = delme bs = 1M count = 10
10 + 0 записей в
10 + 0 записей
10485760 байт (10 МБ) скопировано, 0,00566339 с, 1,9 ГБ / с

Чтобы отключить кеширование Linux, мы можем смонтировать файловую систему синхронно:

 mount -o remount, sync / mnt / raid6

Это не совсем так ... синхронизация не просто отключает кеширование, как вы хотите в тесте. Он превращает каждый результат записи в команду «sync», что означает полную очистку кеша до диска.

Вот здесь сервер, чтобы лучше объяснить:

$ dd if=/dev/zero of=testfile bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.183744 s, 2.9 GB/s

$ dd if=/dev/zero of=testfile bs=1M count=500 conv=fdatasync
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 5.22062 s, 100 MB/s

conv = fdatasync просто означает сброс после записи, и скажу вам время с учетом этого слива. В качестве альтернативы вы можете сделать:

$ time ( dd if=/dev/zero of=testfile bs=1M count=500 ; sync )
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.202687 s, 2.6 GB/s

real    0m2.950s
user    0m0.007s
sys     0m0.339s

А затем вычислить МБ / с из 2,95 секунды реального времени, а не из приведенных выше 0,2 секунды. Но это уродливо и требует больше работы, так как статистика, выводимая dd, не включает синхронизацию.

Если вы использовали «синхронизацию», вы бы сбрасывали каждую запись ... может быть, это означает каждый блок, который будет работать очень медленно. "sync" следует использовать только в очень строгих системах, например. базы данных, в которых потеря одной транзакции из-за сбоя диска недопустима (например, http://romanrm.ru/en/dd-benchmark

И еще одно замечание: ваш тест, который вы делаете таким образом, полностью верен, на мой взгляд, хотя и не действителен во мнениях многих других. Но это не испытание в реальной жизни. Это однопоточная последовательная запись. Если ваш случай использования в реальной жизни такой, например. отправка больших файлов по сети, тогда это может быть хорошим тестом. Если ваш вариант использования отличается, например. ftp-сервер с 500 людьми, загружающими небольшие файлы одновременно, тогда это не очень хорошо.

Кроме того, для достижения наилучших результатов вы должны использовать случайно сгенерированный файл в ОЗУ. Некоторые файловые системы слишком умны, если вы скармливаете им нули. например. в Linux с использованием файловой системы RAM tmpfs, которая смонтирована в / dev /. (и в некоторых системах / dev / random или / dev / urandom работает медленно, поэтому используйте другой ... я забыл, какой, но в обоих случаях они будут намного меньше, чем ОЗУ, поэтому не используйте напрямую)

dd if=/dev/random of=/dev/shm/randfile bs=1M count=500
dd if=/dev/shm/randfile bs=1M count=500 conv=fdatasync