Измерение скорости чтения-записи носителей с помощью утилиты dd

Недавно, я вновь побывал в роли технического эксперта, когда занимался переводом книги «Understanding Software Dynamics» от Richard L. Sites. В ходе работы над главой — про скорость работы с жёстким диском, мне поступил вопрос от коллеги: каким образом можно просто и быстро измерить скорость чтения и записи твердотельных носителей информации, в разрабатываемых в компании устройствах? При этом стояла задача реализовать всё это наиболее простыми способами, чтобы они были переносимы между совершенно разными платформами и архитектурами. Носители же информации могут быть любыми: USB Flash, eMMC, SD, NAND и прочее, прочее. Единственное, что их объединяет — это Linux.

Задача захватила меня с головой...Тем более, когда я понимал, что решение не такое тривиальное, как хотелось бы. При этом нужно дать какой-то простой и переносимый инструмент для его реализации.

Решение, с одной стороны, очевидное — это утилита dd. Но так ли просто измерить скорость твердотельного диска, а я уж не говорю о настоящем жёстком диске? В попытке ответить на этот вопрос моему коллеге, у меня получилось настоящее исследование, которым и хочу с вами поделиться.

Поскольку при тестировании диска нужно производить как операции записи на диск, так и операции чтения, то дабы сократить объём статьи в два раза, буду приводить примеры только операции записи на диск, как наиболее тяжёлые. Но всё что я тут ниже буду рассказывать, относится и к операциям чтения, просто цифры будут немного другие. Но всё что я тут ниже буду рассказывать, относится и к операциям чтения, просто цифры будут немного другие.

❯ Пару слов об утилите dd

Для тех, кто не знаком с этой утилитой или не пользуется *nix системами краткий ликбез про эту команду. Конечно, лучше, чем в вики не скажешь, поэтому позволю несколько цитат оттуда:

dd (data definition) — программа UNIX, предназначенная как для копирования, так и для конвертации файлов. Название унаследовано от оператора DD (Data Definition) из языка JCL.
Название утилиты dd иногда в шутку расшифровывают, как «disk destroyer», «data destroyer», «delete data» или «добей диск», так как утилита позволяет производить низкоуровневые операции на жёстких дисках — при малейшей ошибке (такой, как реверс параметров if и of) можно потерять часть данных на диске (или даже все данные). Есть и более «уважительное» прозвище — «disk duplicator», потому что на практике основное её применение — это копии, образы и бэкапы разделов.

Я всё же настоятельно рекомендую прочитать man dd перед её использованием, поскольку её возможности достаточно обширны, но кратко описание команды можно также взять с вики:

Базовые параметры

dd [--help] [--version] [status] [if=файл] [of=файл] [ibs=байты] [obs=байты] [bs=байты] [cbs=байты] [skip=блоки] [seek=блоки] [count=блоки] [conv={ascii, ebcdic, ibm, block, unblock, lcase, ucase, swab, noerror, notrunc, sync}]

• status=progress — отображает статистику передачи, возможны 3 варианта 'none', 'noxfer', 'progress' GNU Coreutils 8.24+ (Ubuntu 16.04 and newer).
• if=файл — читает данные из файла вместо стандартного ввода.
• of=файл — пишет данные в файл вместо стандартного вывода.
• bs=n — размер блока.
• ibs=nn и obs=nn — задаёт, сколько байтов нужно считывать или записывать за раз.
• count=n — сколько блоков скопировать.
• seek=n — сколько блоков пропустить от начала в выходном файле перед копированием.
• skip=n — сколько блоков пропустить от начала во входном файле перед копированием.
• conv=фильтр, фильтр — применить фильтры конвертации. Типы фильтров:
• • ascii — сконвертировать в ASCII из EBCDIC…
  • ebcdic — …и наоборот.
  • block — выравнивание блоков.
  • lcase — преобразовать к нижнему регистру.
  • ucase — преобразовать к верхнему регистру.
  • swab — менять местами пары байт.
  • noerror — игнорировать ошибки ввода-вывода.

Простой пример утилиты dd — это как сделать копию главной загрузочной записи MBR жёсткого диска:

dd if=/dev/hda of=bootloader.mbr bs=512 count=1

ВАЖНО: При работе с утилитой dd нужно соблюдать большую внимательность, потому что ей легко и просто уничтожить все данные на жёстком диске. Недавно, вышеупомянутый коллега, таким образом снёс себе систему. Да, чего уж там скрывать, я сам неоднократно стирал совсем не те диски. Поэтому обычно по десять раз всё проверяю.

Резюмируя, утилита позволяет читать и записывать данные как на диск, так и в файл. А поскольку в операционных системах семейства *nix всё есть файл, то это практически равнозначно! Хотя нет, и ниже поясню почему.

❯ Можно ли dd использовать для тестирования скорости записи и что не так с этим тестом?

Для начала продемонстрирую один эксперимент, демонстрирующий разницу скорости работы утилиты dd.

Смотрите, я хочу создать файл, заполненный нулями. Для этого вычитаю файл-устройство /dev/zero и запишу его в регулярный файл на диске.

Отличие будет в количестве данных считываемых за раз: в первом случае я буду читать 1 байт за раз, а в другом случае 1МиБ. Кстати, особенность операционной системы линукс состоит в том, что она не гарантирует запись на диск после окончания операции dd. Данные просто были скопированы в ядро, поэтому после утилиты dd нужно выполнить команду sync для того, чтобы данные попали на диск из буфера ядра.

Критерием выполнения операции будет общее время исполнения dd и sync.

В результате получится две команды:

Для первого случая, читаем 1 байт за раз и записываем миллион штук:

time $(dd if=/dev/zero of=test.raw bs=1 count=1M && sync)

Во втором случае читаем 1 мегабайт за раз и пишем один раз:

time $(dd if=/dev/zero of=test.raw bs=1M count=1 && sync)

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

Сравните две цифры: 1,910 секунды и 0,01 секунды! Разница в скорости в сто девяносто один раз!!!

А причина достаточно простая, жёсткий диск — это блочное устройство и работа с ним ведётся блоками данных. Если вы читаете или пишете (как в случае выше) 1 байт, вы всё равно записываете блок данных, который больше 1 байта, а может быть размером от 512 и более байт, которое кратно 512 байтам.

Блочные устройства помечаются в папке /dev/ буквой «b»:

Как вы понимаете, размер блока определяется особенностями работы конкретного физического устройства и реализацией драйвера внутри ядра.

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

Таким образом, мы подходим к основной части исследования: какой оптимальный размер блока для записи на диск?

❯ Какой размер блока оптимален для записи на дисковое устройство?

Ответ не совсем очевиден: он зависит от аппаратных особенностей реализации устройства, для памяти типа NAND — это будет блок одного размера (вероятнее размером со страницу), для жёстких дисков другого.

Поэтому я определился с подопытным кроликом. Для этих варварских экспериментов, которые дико снизят ресурс любого флеш-накопителя, решил принести в жертву неиспользуемую флешку на 16 ГБ (обращаю внимание, что реальный её размер 14,32 ГиБ).

Жертвенный носитель

Для того чтобы не лопатить вручную команды, набросал простенький скриптик на питоне, на который я потратил два дня, который запускает команду dd. Да, можно было непосредственно писать в файл прямо с питона, но у меня была задача проверить именно эту утилиту. С исходным файлом кода скрипта можно ознакомиться на гитхабе.

Смысл его в том, что он по очереди перебирает размер блока (bs) от минимального 512 байт до максимального 16МиБ, и записывает данные в указанный пользователем файл.

Практика показала, что оптимально для исследований размер записи не менее 1 ГиБ, и количество записей — не менее 9 (разброс показаний погрешности).

Таким образом, если флешка у нас является файл-устройством /dev/sdg, то команда для тестирования будет выглядеть следующим образом:

sudo python3 dd_speed_test.py -o /dev/sdg -s 1024 -n 9 --logfile="disk_test.txt"

Прошу вас, обязательно проверьте файл-устройство, куда вы пишете, иначе вы потеряете ваши данные!

Поскольку данных много, то я решил брать от них два параметра: среднее и медианное значение. Более доверяю медианному, потому что оно ближе к реальности. Конечно, если бы это было научное исследование, тут хорошо бы учитывать разброс значений, чтобы понимать максимум и минимум. Но не буду перегружать статью. В результате этого эксперимента получил такую табличку:

Ничто так не украшает статью, как хороший график, который построен следующим скриптом.

Время записи 1 ГиБ данных на диск в зависимости от размера блока данных

Видно, что самая быстрая запись идёт блоком — размером 1 киБ, а самая медленная — блоком размером 512 байт (хотя, казалось бы). Размер, который я использую в быту — 1 МиБ, вполне себе находится в допуске самых быстрых.

Обращаю внимание, что эти данные — результаты эмпирического исследования скорости записи на конкретную флешку, хотя, разумеется, с твердотельными накопителями графики, вероятнее всего, будут схожими.

Вывод главы: наиболее оптимальным блоком данных, при непосредственной записи на диск оказался размер в 1 киБ.

А теперь интересный вопрос, а можно ли измерять скорость записи на диск, не стирая данные на нём, а записывая в файл в файловой системе?

❯ Особенности организации записи файла на диск

Для того чтобы показать, как делается запись данных на диск с файловой системой, я сделаю виртуальное файл-устройство и буду его конвертировать в картинку. Если цвет белый — это байт 0xFF, а если какой-либо другой, то значит отличные от 0xFF.
Для удобства, размер картинки с разрешением 1536х1024 выбрал наиболее приближённой к размеру дискетки: 1536*1024=1572864 байт.

Итак, создаю тестовый RAW-файл, заполняя его 0xFF (белый цвет).

time dd if=/dev/zero bs=1572864 count=1 | LC_ALL=C tr "00" "377" | dd of=test.raw

Создаю файловую систему в этом файле

mkfs.fat test.raw -n TEST_FAT

При этом это реальная файловая система в файле, в чём можно убедиться командой file::

file test.raw 
test.raw: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 4, root entries 512, sectors 3072 (volumes <=32 MB), Media descriptor 0xf8, sectors/FAT 3, sectors/track 16, reserved 0x1, serial number 0x1f307932, label: "TEST_FAT   ", FAT (12 bit)

Если сейчас этот RAW-файл с файловой системой конвертнуть в картинку, следующей командой:

convert -size 1536x1024 -depth 8 gray:test.raw fat.png

то мы увидим, что в начале были сделаны какие-то записи структуры файлов. В картинке в GIMP специально сделал синюю рамку, чтобы была лучшая наглядность.

Преобразованная виртуальная файловая система в изображение

Чёрная полоска вначале этой белой картинки и есть файловая система, которая даже занимает какое-то место.

Теперь можно примонтировать файловую систему.

udisksctl loop-setup -f test.raw
udisksctl mount -b /dev/loop0

У меня после первой команды монтируется автоматом в Linux Mint, поэтому вторая не требуется.
Можно посмотреть информацию об этом файл-устройстве:

df -a /dev/loop0
Файл.система   1K-блоков Использовано Доступно Использовано% Cмонтировано в
/dev/loop0          1516            0     1516            0% /media/dlinyj/TEST_FAT

Обратите внимание, что свободно 1516 блоков, что на 20 блоков по одному килобайту меньше, чем размер созданного файла. Вероятнее всего, 20 КиБ занимает файловая система.

А теперь самое главное, ради чего мы здесь собрались, записываем тестовый файл размером 1 МиБ в эту виртуальную файловую систему.

dd if=/dev/zero of=/media/dlinyj/TEST_FAT/test bs=1M count=1 && sync

И смотрим, как же выглядит файловая система после записи. Просто смотреть на картинку после записи особого смысла нет, поэтому сделаю diff полученного файла с тем, который был до записи:

convert -size 1536x1024 -depth 8 gray:test.raw fat_and_file.png
compare fat.png fat_file.png diff.png

Результирующее изображение произведённых изменений:

Изменения, внесённые в файловую систему виртуального устройства

Большой красный прямоугольник — это как раз наши записанные 1МиБ данных, а тонкая красная полоска — это записи в файловой системе о том, где хранятся эти кластеры данных.

Почему это важно? Потому что на запись каждого блока, надо читать файловую систему и редактировать таблицу данных файловой системы и записывать её обратно. То есть, идёт на каждую порцию данных дополнительные накладные расходы на правку файловой системы. И это означает, что запись на диск в файл должна быть медленнее, чем непосредственная запись на диск.

Но так ли это на самом деле? Ответ вас может сильно удивить, и он удивил даже меня. Она может быть даже быстрее (и будет быстрее, если неверно выбрать размер блока). И сейчас объясню почему.

❯ Измерение скорости записи на диск, при работе с файлом

Прежде чем делать выводы, давайте также проведём исследование с созданием файла на флешке, с использованием утилиты dd и проверим, какой же размер блока будет оптимальным.

Для начала, после зверских опытов с флешкой, создадим на ней файловую систему. Первично диск нужно разметить командой fdisk:

После этого, во вновь созданном разделе создаю файловую систему FAT32. И монтирую её.

mkfs.fat -F 32 /dev/sdg1 -n TEST_FLASH
udisksctl mount -b /dev/sdg1

Что ж, настало время теста:

python3 dd_speed_test.py -o /media/dlinyj/TEST_FLASH/testfile -s 1024 -n 9 --logfile="file_test.txt"

Результаты такого тестирования представлены в таблице ниже.

И конечно, красивый график, куда ж без него.

Время записи в регулярный файл на диске в зависимости от размера блока

Видно, что чем больше размер блока, тем быстрее идёт запись. Но внимательный читатель посмотрел на числа, и всё встаёт на свои места, если наложить график времени непосредственной записи на диск — на график записи в файл.

Сравнение времени записи прямой на диск и в файл в зависимости от размера блока

Можно увидеть, что по сути — размер bs никак не влияет на скорость записи в файл! А скорость записи показывает практически самые лучшие показатели, как при непосредственной записи на диск.

Почему же так получается, и можно ли тестировать таким образом скорость записи на диск? Всё достаточно просто: происходит кеширование внутри ядра, в том числе записей в файловую систему. И потом запись происходит на самой оптимальной скорости на диск, прямо из буфера ядра. Как можно убедиться, на 1, 2 и 4 киБ таки проигрывает максимальной скорости записи на диск.

А можно ли получить реальную скорость записи, когда запись производится непосредственно? Да, отключив буферизацию.

❯ Отключаю буферизацию записи

Отключить кеширование можно с помощью команды hdparm, с помощью опции -W, которая согласно документации, позволяет управлять размером буфера.

-W Get/set the IDE/SATA drive´s write-caching feature.

Сделаем его равным нулю:

sudo hdparm -W0 /dev/sdc

/dev/sdc:
 setting drive write-caching to 0 (off)
SG_IO: bad/missing sense data, sb[]:  f0 00 05 00 00 00 00 14 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  f0 00 05 00 00 00 00 14 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  f0 00 05 00 00 00 00 14 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 write-caching = not supported

Ну и произведём тестирование с отключенным буфером (бедная флешка):

python3 dd_speed_test.py -o /media/dlinyj/TEST_FLASH/disk_file -s 1024 -n 9 --logfile="cache_off.txt"

В результате получаются цифры намного более близкие к реальности, чем в предыдущем тесте.

Ну и конечно же график.

Время записи в файл на диске при отключенном кешировании

Ну вот, совсем другие числа. Отличаются практически в три раза!

Ну и нагляднее всего увидеть все три варианта на одном графике. Чтобы вы не запутались:

• Первая группа – это просто запись в файл.
• Вторая группа – это запись с отключенным кешированием.
• Третья – это непосредственная запись на диск.

Сравнение времени записи всех возможных вариантов при разной величине блока данных

Как можно увидеть, что самый быстрый способ записать данные на диск – это непосредственная запись с оптимальным размером блока.

❯ Вывод

Да, я прекрасно понимаю, что есть куча хороших утилит, для измерения скорости работы с жёстким диском. И уверен, что под Линукс есть много хорошего ПО. При этом — они более качественно, а главное более адаптивно к ядру и железу — проведут тестирования оборудования.

Однако, все эти утилиты нужно искать, собирать, проверять тестировать. А когда хочется здесь и сейчас, утилита dd вполне может показать в общих чертах относительные параметры, с которыми производилась запись. Но, оценивать придётся не те числа, с какой скоростью была произведена запись, а время выполнения команды, вместе с командой sync и помнить, что sync синхронизирует не только ваши данные, а вообще все буфера ядра. В общем и целом, неизвестных в этом вопросе пока может быть даже больше, чем известных.

Отвечая на главный вопрос коллеги: можно ли измерить скорость чтения-записи, работая с файлом?

Отвечаю: скорее нет, чем да. Слишком большая погрешность кеширования. В целом — это не самый оптимальный способ измерения скорости работы с диском. Поэтому, если точность параметров не нужна и допустимо измерение в попугаях (такое часто бывает), этим способом можно пользоваться.

❯ Полезные ссылки

1. Репозиторий проекта к этой статье, если вы вдруг захотите повторить эти опыты.
2. Если вы захотите писать свой тестер жёстких дисков, лучше использовать этот код. Это лучше, чем писать кривые непереносимые обёртки над dd.
3. Linux and Unix Test Disk I/O Performance With dd Command — Весьма неплохая статья на английском, где подробно расписано, почему всё так получается и как оно работает. По сути, то что я тут рассказал, только в более сжатом виде.

Если вам интересна металлообработка, всякие DIY штуки, погроммирование и linux, то вы можете следить за мной ещё в телеграмме.

---