Производительность файловых систем с обратной связью

Я провел небольшое тестирование операций записи в устройстве с обратной связью. Вот вывод:

• Если вы выполняете синхронизацию после каждой записи, устройство с обратной связью работает значительно хуже (почти вдвое медленнее).
• Если вы разрешите кэшированию диска планировщику ввода-вывода выполнять свою работу, то почти не будет никакой разницы между использованием устройства с обратной связью и прямым доступом к диску.

Результаты тестов

Во-первых, я провел тест на устройстве с обратной связью в tmpfs объемом 8 ГБ и с устройством с обратной связью в этом устройстве с обратной связью (с синхронизацией после каждой операции записи):

ext4 в tmpfs:

Measured speed: 557, 567, 563, 558, 560, 559, 556, 556, 554, 557
Average speed : 558.7 MB/s  (min 554  max 560)

ext4 в extf в tmpfs:

Measured speed: 296, 298, 295, 295, 299, 297, 294, 295, 296, 296
Average speed : 296.1 MB/s  (min 294  max 299)

Очевидно, есть некоторая разница в производительности при использовании устройств с обратной связью с синхронизацией при записи.
Затем я повторил тот же тест на своем жестком диске.
ext4 (HDD, 1000 МБ, 3 раза):

Measured speed: 24.1, 23.6, 23.0
Average speed : 23.5 MB/s  (min 23.0  max 24.1)

ext4 в ext4 (HDD, 945 МБ):

Measured speed: 12.9, 13.0, 12.7
Average speed : 12.8 MB/s  (min 12.7  max 13.0)

Тот же тест на жестком диске, теперь без синхронизации после каждой записи (time (dd if=/dev/zero bs=1M count=1000 of=file; sync), измеряется как <size>/<time in seconds>).
ext4 (HDD, 1000 МБ):

Measured speed: 84.3, 86.1, 83.9, 86.1, 87.7
Average speed : 85.6 MB/s  (min 84.3  max 87.7)

ext4 в ext4 (HDD, 945 МБ):

Measured speed: 89.9, 97.2, 82.9, 84.0, 82.7
Average speed : 87.3 MB/s  (min 82.7  max 97.2)

(удивительно, что тест loopback выглядит лучше, чем тест raw-disk, предположительно из-за меньшего размера устройства loopback, поэтому на фактическую синхронизацию с диском тратится меньше времени)

Настройка теста

Сначала я создал петлевую файловую систему размером 8G в моем / tmp (tmpfs):

truncate /tmp/file -s 8G
mkfs.ext4 /tmp/file
sudo mount /tmp/file /mnt/
sudo chown $USER /mnt/

Затем я установил базовый уровень, заполнив смонтированный файл обратной связи данными:

$ dd if=/dev/zero bs=1M of=/mnt/bigfile oflag=sync
dd: error writing '/mnt/bigfile': No space left on device
7492+0 records in
7491+0 records out
7855763456 bytes (7.9 GB) copied, 14.0959 s, 557 MB/s

После этого я создал еще одно устройство обратной петли в предыдущем устройстве обратной петли:

mkdir /tmp/mountpoint
mkfs.ext4 /mnt/bigfile
sudo mount /mnt/bigfile /tmp/mountpoint
sudo chown $USER /tmp/mountpoint

И снова запустил тест десять раз:

$ dd if=/dev/zero bs=1M of=/tmp/mountpoint/file oflag=sync
...
7171379200 bytes (7.2 GB) copied, 27.0111 s, 265 MB/s

а затем размонтировал тестовый файл и удалил его:

sudo umount /tmp/mountpoint
sudo umount /mnt

(аналогично для теста на HDD, только я еще добавил count=1000 чтобы тест не заполнил весь мой диск)
(а для проверки отсутствия записи при синхронизации я запустил dd и sync операция)

У меня не было проблем. Все было как скала. Кэш файловой системы и планировщик ввода-вывода в Linux достаточно разумны, чтобы не иметь заметной разницы между запросом диска напрямую и запросом раздела файла на диске.